[Noyau Linux] Version 6 et des brouettes

Recherche :

Mot : Pseudo : Filtrer Aller à la page :
Page : 1 2 3 4 5 .. 139 140 141 .. 180 181 182 183 184 185 Page Suivante Page Précédente Bas de page
Auteur	Sujet : [Noyau Linux] Version 6 et des brouettes

Photonium

Masse atomique : 0 uma

Reprise du message précédent :

Gf4x3443 a écrit :

Certes.

En même temps il y a une prise de conscience de la perte de la qualité du code du noyau, et je ne vois absolument pas en quoi cela devrait remettre en cause le développement actuel. Je le trouve d'ailleurs bien plus cohérent et adapté à ce genre de projet.

Quitte à retarder l'avancement des fonctionnalités, c'est tout a leur honneur de venir dire que les efforts vont se concentrer sur de la résolution de bugs. D'autres boites ne menent pas cette politique depuis belle lurette...

Je suis bien trop mal placé pour ouvrir ma gueule sur le schéma de developpement du noyau. Mais aucune des 2 façons de développer me parait meilleure pour un projet comme ca. Il faut noter que les cycles instables ne servaient pas à la base à ajouter des nouvelles fonctionnalités mais à repenser le noyau ce qui pouvait être nécessaire même au prix de l'incompatibilité.

D'un autre coté, la nouvelle façon, c'est sur le papier : free-style pendant 2 semaines puis on debuggue. A mon avis, ca peut vite partir en vrille aussi ce truc-là. Et c'est peut-être ce qui s'est passé. Maintenant, je ne sais pas comment Linus s'y prend, donc je peux pas vraiment avoir de jugement.

Evidemment, s'arrêter pour corriger des bugs est une sage décision et comme toi je l'approuve. C'est dommage quand même d'en arriver là.

Message cité 1 fois

---------------
A savoir : la dimension de Hausdorff du chou-fleur a été calculée et vaut 2.33

Publicité

Photonium

Masse atomique : 0 uma

Mjules a écrit :

je te parle du mode de fonctionnement pré-2.6...

Moi aussi

Mjules a écrit :

j
Quand Suse backportait plus d'un millier (1000) de patch de la branche 2.5 pour avoir un noyau 2.4 à son goût, c'est à dire supportant du matériel récent surtout.

Bah, je crois que c'est des mentalités que j'aurais toujours du mal à comprendre. Je suis peut-être devenu très patient avec Debian

---------------
A savoir : la dimension de Hausdorff du chou-fleur a été calculée et vaut 2.33

Gf4x3443

Killing perfection

Photonium a écrit :

Evidemment, s'arrêter pour corriger des bugs est une sage décision et comme toi je l'approuve. C'est dommage quand même d'en arriver là.

Ah ca en revanche... Ca aurait du etre fait petit à petit, mais mieux vaut tard que jamais.

Dumbledore

Sinon, on peut reprendre l'ancien mode mais avec un cycle de développement beaucoup plus court : 6 mois ou éventuellement 1 an.

=> Dans le 2.6
On ne fait que de la correction de bug/failles et les seules modifs qu'on fait concernent des changement mineurs n'affectant pas l'architecture ni les API du kernel

=> Dans le 2.7
On fait la foire : changement d'API, architecture, ajout de gros pilotes impliquant des changements profonds risquant de tout casser...

A la fin de l'année, on renome le 2.7 en 2.8 qui passe au stade de maintenance "active" comme expliqué plus haut et on lance un 2.9 pour les 6 mois à venir.
Et surtout, on tient les délais !

Message cité 2 fois

Gf4x3443

Killing perfection

Les delais c'est pas le genre de chose qu'on tient facilement dans ce genre d'entreprise (au sens large du terme)

M'enfin un 2.8 on risque d'attendre un peu avant de le voir débarquer tout de même.

belgique

Dumbledore a écrit :

En même temps on va pas changer d'API/architecture pour le plaisir de tout changer

THRAK

- THR4K -

Photonium a écrit :

Alors là, je trouve çà carrement à chier. C'est pas au paquetageur de réparer les merdes de Linus et de sa bande.
Dire moi je fais joujou à faire du code dégueulasse et experimental, et vous vous le débugguer, c'est n'importe quoi. La seule véritable raison d'installer les noyaux des distribs, c'est pour garder l'harmonie de la distrib et pas avoir des programmes qui viennent d'on ne sait où (orthographe ?).

Heu j'ai l'impression que tu oublies dans cette histoire que c'est le principe même sur lequel repose le développement des Logiciels Libres que tu sembles vouloir remettre en question, alors que ce modèle à largement fait ses preuves jusqu'à présent.

Linus et sa bande bossent sur le noyau avec une gestion de branche qui ne présente qu'une manière plus pratique/efficace de travailler dessus ; une des stratégies de Linus est de faire évoluer rapidement le noyau, et c'est précisément ce qu'il fait. Après s'il y a des bugs, Linus et sa bande ne le font quand même pas exprès, ils n'ont rien à y gagner, il est logique quand tu effectues de nombreux changements/refontes de provoquer l'apparition de nouveaux bugs ou alors il faut ralentir/figer le développement pour ne pas craindre d'en voir apparaître.

Les retours de toute la communauté permettent ensuite de les fixer (que ce soit des simples reports ou bien des patches), c'est tout simplement la méthode la plus pertinente pour contribuer à l'amélioration d'un programme, précisément le point qui fait la force des logiciels libres par rapport aux logiciels proprios. Je rappelle quelques éléments essentiels énoncés à ce sujet par Eric S. Raymond dans la "Cathédrale vs le Bazard" :

Citation :

Linux a remis en cause une grande partie de ce que je croyais savoir. J'avais prêché l'évangile selon Unix sur l'utilisation de petits outils, le prototypage rapide et la programmation évolutive, depuis des années. Mais je pensais aussi qu'il existait une certaine complexité critique au delà de laquelle une approche plus centralisée, plus a priori, était nécessaire. Je pensais que les logiciels les plus importants (comme les systèmes d'exploitation et les très gros outils comme Emacs) devaient être conçus comme des cathédrales, soigneusement élaborés par des sorciers isolés ou des petits groupes de mages travaillant à l'écart du monde, sans qu'aucune version bêta ne voie le jour avant que son heure ne soit venue.

Le style de développement de Linus Torvalds - distribuez vite et souvent, déléguez tout ce que vous pouvez déléguer, soyez ouvert jusqu'à la promiscuité - est venu comme une surprise. À l'opposé de la construction de cathédrales, silencieuse et pleine de vénération, la communauté Linux paraissait plutôt ressembler à un bazar, grouillant de rituels et d'approches différentes (très justement symbolisé par les sites d'archives de Linux, qui acceptaient des contributions de n'importe qui) à partir duquel un système stable et cohérent ne pourrait apparemment émerger que par une succession de miracles.

Le fait que ce style du bazar semblait fonctionner, et bien fonctionner, fut un choc supplémentaire. Alors que j'apprenais à m'y retrouver, je travaillais dur, non seulement sur des projets particuliers, mais encore à essayer de comprendre pourquoi le monde Linux, au lieu de se disloquer dans la confusion la plus totale, paraissait au contraire avancer à pas de géant, à une vitesse inimaginable pour les bâtisseurs de cathédrales.

[...]

Le fait que beaucoup d'utilisateurs sont également des bidouilleurs est une autre force de la tradition Unix, et c'est une caractéristique que Linux a poussée avec bonheur dans ses derniers retranchements. De plus, la libre disponibilité du code source en fait des bidouilleurs efficaces. Ceci peut se révéler incroyablement utile pour réduire le temps de débogage. Avec un peu d'encouragement (ils n'en réclament pas beaucoup), vos utilisateurs diagnostiqueront les problèmes, suggéreront des corrections, et vous aideront à améliorer le code bien plus rapidement que vous n'auriez pu le faire, si vous étiez laissé à vous même.

6. Traiter vos utilisateurs en tant que co-développeurs est le chemin le moins semé d'embûches vers une amélioration rapide du code et un débogage efficace.

[...]

7. Distribuez tôt. Mettez à jour souvent. Et soyez à l'écoute de vos clients.

La grande innovation de Linus ne fut pas tant de faire cela (c'était une tradition du monde Unix depuis un bon moment, en tout cas sous une forme proche), que de donner à cette idée un niveau d'intensité correspondant à la complexité de ce qu'il développait. En ces temps reculés (autour de 1991), il lui arrivait de mettre à jour son noyau plusieurs fois par jour ! Comme il cultivait sa base de co-développeurs et recherchait des collaborations sur Internet plus que quiconque jusque là, cela a marché.

[...]

Linus cherchait directement à maximiser le nombre de personnes-heures jetées dans la bataille du débogage et du développement, au prix éventuel d'une certaine instabilité dans le code et de l'extinction de sa base d'utilisateurs si un quelconque bogue sérieux se révélait insurmontable. Linus se comportait comme s'il croyait en quelque chose comme:

8. Étant donné un ensemble de bêta-testeurs et de co-développeurs suffisamment grand, chaque problème sera rapidement isolé, et sa solution semblera évidente à quelqu'un.

Ou, moins formellement, ``Étant donnés suffisamment d'observateurs, tous les bogues sautent aux yeux.'' C'est ce que j'appelle: ``La Loi de Linus''.

Ma première formulation de cette loi était que chaque problème ``semblera clair comme de l'eau de roche à quelqu'un''. Linus a objecté qu'il n'était pas nécessaire, et que d'ailleurs ce n'était pas le cas en général, que la personne qui comprenne un problème soit la personne qui l'ait d'abord identifié. ``Quelqu'un trouve le problème,'' dit-il, ``et c'est quelqu'un d'autre qui le comprend. Je pousserai le bouchon jusqu'à dire que le plus difficile est de trouver le problème.'' Mais le principal est que ces deux événements se produisent en général vite.

C'est là, je pense, la différence fondamentale sous-jacente aux styles de la cathédrale et du bazar. Dans la programmation du point de vue de la cathédrale, les bogues et les problèmes de développement représentent des phénomènes difficiles, ennuyeux, insidieux, profonds. Il faut à une poignée de passionnés des mois d'observations minutieuses avant de bien vouloir se laisser convaincre que tous les bogues ont été éliminés. D'où les longs intervalles séparant les mises à jour, et l'inévitable déception quand on se rend compte que la mise à jour tant attendue n'est pas parfaite.

Dans le point de vue bazar, d'un autre côté, vous supposez qu'en général, les bogues sont un phénomène de surface -- ou, en tout cas, qu'ils sautent rapidement aux yeux lorsqu'un millier de co-développeurs avides se précipitent sur toute nouvelle mise à jour. C'est pourquoi vous mettez à jour souvent afin de disposer de plus de corrections, et un effet de bord bénéfique est que vous avez moins à perdre si de temps en temps, un gros bogue vous échappe.

Et voilà. C'est tout. Si la ``Loi de Linus'' est fausse, alors tout système aussi complexe que le noyau Linux, subissant les bidouilles simultanées d'autant de mains que ce fut le cas du noyau Linux, aurait dû à un certain moment s'effondrer sous le poids des interactions néfastes et imprévues, sous le poids de bogues ``profonds'' non découverts. D'un autre côté, si elle est juste, elle suffit à expliquer l'absence relative de bogues dans Linux.

[...]

Plus d'utilisateurs trouvent plus de bogues parce que l'ajout de nouveaux utilisateurs introduit de nouvelles manières de pousser le programme dans ses derniers retranchements. Cet effet est amplifié quand les utilisateurs se trouvent être des co-développeurs. Chacun d'entre eux a une approche personnelle de la traque des bogues, en utilisant une perception du problème, des outils d'analyse, un angle d'attaque qui lui sont propres. L'``effet de Delphes'' semble précisément fonctionner grâce à cette variabilité. Dans le contexte spécifique du débogage, la diversité tend aussi à réduire la duplication des efforts.

[...]

Enfin, il faut savoir ce que l'on veut, on a d'un côté certains qui vont râler parce que le matos récent ne bénéficie pas assez rapidement d'un support sous GNU/Linux et d'un autre côté on a ceux qui vont râler parce que les choses bougent trop rapidement et induit (forcément) des bugs...

Message cité 1 fois

---------------
THRAK (def.) : 1) A sudden and precise impact moving from intention, direction and commitment, in service of an aim. 2) 117 guitars almost striking the same chord simultaneously.

Photonium

Masse atomique : 0 uma

THRAK a écrit :

En fait, on est pas sur la même longueur d'onde. Je suis pour le logiciel libre, en ce sens que si ca marche pas, je peux regarder le code source et le réparer s'il le faut. Je crois que je vais laisser tomber la phase upload en upstream mais çà c'est un autre problème.
Maintenant, ce n'est pas au paquetageur de "devoir" debugguer/corriger les noyaux parce que cela n'a pas été fait assez longtemps en upsteam. Peut-être que le problème est que justement les versions rc ne sont pas assez testées (d'ailleurs c'est sur : Linus le dit lui même). Mais je pense pas que les versions stable 2.6.Z soient à utiliser pour des retours de la communauté. Je pense que justement s'il y a des retours à ce niveau, alors il y a un problème.

THRAK a écrit :

Toujours le même troll. Bah, je suppose que comme moi, tu n'as pas envie de troller là dessus. De toutes façons, mon avis ne vaut rien du fait que je ne suis pas assez impliqué dans le développement. Je m'arrête là.

---------------
A savoir : la dimension de Hausdorff du chou-fleur a été calculée et vaut 2.33

fl0ups

東京 - パリ - SLP

Photonium a écrit :

Alors là, je trouve çà carrement à chier. C'est pas au paquetageur de réparer les merdes de Linus et de sa bande.
Dire moi je fais joujou à faire du code dégueulasse et experimental, et vous vous le débugguer, c'est n'importe quoi. La seule véritable raison d'installer les noyaux des distribs, c'est pour garder l'harmonie de la distrib et pas avoir des programmes qui viennent d'on ne sait où (orthographe ?).

:heink:
Mais de quoi tu parles?
J'espere ne pas te vexer mais ca faisait longtemps que je n'avais pas vu autant de conneries en aussi peu de phrases.

Photonium a écrit :

Maintenant, je connais pas énormement l'architecture du code du noyau, mais s'il faut passer par un cycle 2.8 très long pour revenir à qqch de plus propre, alors je vois pas où est le problème. Peut-être que pour vous, ne pas installer de kernel pendant plusieurs mois, çà vous plait pas mais mettez vous à la place d'un développeur du noyau qui s'arrache les cheveux parce que c'est mal foutu. Peut-être que pour lui, un 2.8 serait le paradis.

:??: :heink:
Il n'a jamais ete question que le kernel soit mal foutu.
Ce sont certains utilisateurs qui n'apprecient pas le mode de dev actuel, car comme on rajoute des fonctionalites dans des kernels stables, on rajoute aussi potentiellement des bugs.
Les developpeurs du kernel, eux, ils preferent nettement ce mode de dev.

Dumbledore a écrit :

Sinon, on peut reprendre l'ancien mode mais avec un cycle de développement beaucoup plus court : 6 mois ou éventuellement 1 an.

Ca ne marche pas. Quand le 2.2 est sortit apres de longues annees de gestation, promis, jure, crache, le cycle de dev du 2.4 allait etre plus rapide et il sortait dans un an. Et rebelotte pour le 2.6 a la sortie du 2.4. En fait ca a dure au moins 3 ans pour les 2.

Et personne n'interdit a ceux qui n'aiment pas le 2.6 de considerer que le kernel stable est le 2.4.

Message cité 2 fois

---------------
Fluctuat nec mergitur

Photonium

Masse atomique : 0 uma

fl0ups a écrit :

:heink:
Mais de quoi tu parles?
J'espere ne pas te vexer mais ca faisait longtemps que je n'avais pas vu autant de conneries en aussi peu de phrases.

Je répondais à une assertion qui me semble absurde. C'est tout.

Citation :

[...]pour ceux qui trouvent la branche 2.6.x.x trop instable en l'état [...], pour régler cette problématique rappelons qu'il existe spécialement les noyaux patchés fournis par les différentes distributions

Le "spécialement" n'est pas passé. Je n'ai jamais dit formellement que Linus codait mal. Faut pas sortir mes propos de leur contexte.

fl0ups a écrit :

Je pensais que j'avais pris assez de pincettes pour dire que SI le noyau nécessitait un 2.8 parce qu'il commençait à être bancal, alors çà ne me gênerait pas. Et de plus, il n'est vraiment pas dit que le noyau est propre niveau code. J'ai déjà entendu pas mal de monde disant que, parfois, c'était limite....

Message cité 1 fois

---------------
A savoir : la dimension de Hausdorff du chou-fleur a été calculée et vaut 2.33

Publicité

THRAK

- THR4K -

Photonium a écrit :

Ca signifie que tu comptes sur l'apparition d'une nouvelle branche toute fraîche pour pallier aux "nombreux" problèmes de la branche actuelle alors que celle-ci va arriver à maturité, c'est-à-dire en voie de stabilisation ? :sarcastic: Franchement il y a dans ce cas des risques que tu sois à nouveau déçu (pendant un certains temps au moins) vu le temps de stabilisation que demande une nouvelle branche (je te renvoie aux branches qui sont sorties jusqu'ici).

Enfin ça peut paraître paradoxal, mais la propreté du code n'est pas forcément représentative de son bon ou mauvais fonctionnement ; c'est d'ailleurs un sujet de débat récurrent entre Linus et Alan (Cox). Ce dernier préfère une approche visant à fixer les problèmes par des hacks parfois très sales pour éviter certains effets de bord (coût en temps, apparition de bugs supplémentaires) que peut induire une réécriture directe des portions de code en cause. Comme celle-ci est différée, le code peut ainsi rester un certain temps assez dégueu avant de subir un bon nettoyage, mais sans être moins efficace que s'il ne corrigeait pas les problèmes ou s'il en faisait naître des nouveaux.

Certains utilisateurs sont même persuadués qu'un noyau patché dans tous les sens est synonyme d'une mauvaise qualité, d'instabilité, d'emmerdes en bref. Cette certitude n'a de réalité que du point de vue psychologique et relève presque d'une forme de maniaquerie, de même qu'un code pas propre va soudainement faire apparaître une foule de problèmes aux yeux de ces mêmes utilisateurs... Or un noyau patché est tout simplement un noyau qui bénéficie d'un certain suivi et de correctifs.

Message cité 1 fois
Message édité par THRAK le 14-05-2006 à 02:55:19

---------------
THRAK (def.) : 1) A sudden and precise impact moving from intention, direction and commitment, in service of an aim. 2) 117 guitars almost striking the same chord simultaneously.

Photonium

Masse atomique : 0 uma

THRAK a écrit :

Je n'attends plus rien du noyau. Il y a un temps au tout début où j'avais besoin de certaines features. Maintenant, mon système tourne sans problème niveau noyau et j'ai d'autres préoccupations. Par ailleurs, cela fait plusieurs versions du noyau qui me passent entre les mains dont je ne vois pas la différence.

Par contre, si les prochains noyaux merdent, je reviendrais à celui d'aujourd'hui et je les laisserai faire leur boulot.

Voila. Sur ce, bonne nuit...

---------------
A savoir : la dimension de Hausdorff du chou-fleur a été calculée et vaut 2.33

Gf4x3443

Killing perfection

Toi peut etre

Pour d'autres non: meilleur support de la virtualisation, nettoyage, optimisations et sécurité... Sans compter le support des drivers.

Et ca fait un prétexte pour faire mettre à jour les drivers binaires de certains fabriquants.

Dumbledore

fl0ups a écrit :

Il me semblait évident que les ambitions pour la nouvelle version doivent être adaptées au temps disponible...

Mjules

Modérateur
Parle dans le vide

un très bon article de LWN sur le sujet des bugs dans le noyau :
http://lwn.net/Articles/183053/

---------------
Celui qui pose une question est idiot 5 minutes. Celui qui n'en pose pas le reste toute sa vie. | Membre du grand complot pharmaceutico-médico-scientifico-judéo-maçonnique.

Profil supprimé

et de 17
http://www.kernel.org/pub/linux/ke [...] -2.6.16.17

athome

2.6.16.18
http://www.kernel.org/pub/linux/ke [...] -2.6.16.18

j_c_p

Linux user

L'alerte associée au 2.6.16.18 : http://www.frsirt.com/bulletins/5272

jikay

fl0ups a écrit :

Tu parles du lowmem avec 1Go de ram? Je l'ai active et j'ai pas de probleme avec les drivers nvidia ou ipw3945

Salut,
pourrais-tu nous donner la distribution que tu utilises ?
Je cherche à faire marche le wifi sous Linux sur un portable Core Duo avec chipset Wifi Intel 3945ABG.
J'ai la dernière Kaella (Kaella 2.1), mais ni le wifi, ni l'ethernet ne sont reconnus par cette distribution.

Merci

Photonium

Masse atomique : 0 uma

Voici le 2.6.16.19

Citation :

commit 11091f6a4a11feb5794aef9307c428838129ea02
Author: Marcel Holtmann <marcel@holtmann.org>
Date: Fri May 26 13:50:46 2006 +0200

[PATCH] NETFILTER: Fix small information leak in SO_ORIGINAL_DST (CVE-2006-1343)

It appears that sockaddr_in.sin_zero is not zeroed during
getsockopt(...SO_ORIGINAL_DST...) operation. This can lead
to an information leak (CVE-2006-1343).

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>

http://kernel.org/pub/linux/kernel [...] -2.6.16.19

---------------
A savoir : la dimension de Hausdorff du chou-fleur a été calculée et vaut 2.33

athome

2.6.16.20 out
http://www.kernel.org/pub/linux/ke [...] -2.6.16.20

python

z'êtes en retard

Je suis déjà au 2.6.17-rc5 avec mkinitcpio qui remplace mkinitrd

Message cité 2 fois
Message édité par python le 06-06-2006 à 02:02:05

Photonium

Masse atomique : 0 uma

python a écrit :

z'êtes en retard

Je suis déjà au 2.6.17-rc5 avec mkinitcpio qui remplace mkinitrd

Bof, tu sais ca fait plus mal quand on arrive vite sur un mur que quand on y arrive plus lentement...

---------------
A savoir : la dimension de Hausdorff du chou-fleur a été calculée et vaut 2.33

j_c_p

Linux user

python a écrit :

z'êtes en retard

Je suis déjà au 2.6.17-rc5 avec mkinitcpio qui remplace mkinitrd

Tu es aussi à la bourre vu que le 2.6.17-rc6 est sorti .

KikitheKing

Kiki le Vrai !

2.6.17 final out

Message cité 1 fois

simple_stupid

Keep It Simple Stupid

KikitheKing a écrit :

2.6.17 final out

C'est la version que j'attendais le plus!
Yes!

Citation :

Being named "Crazed Snow-Weasel" instills a lot of confidence in this
release, so I'm sure this will be one of the better ones.

Message édité par simple_stupid le 18-06-2006 à 10:33:14

rockbox

Au chiotte l'équipe de France

Passage en douleur en 2.6.17 sur ma Débian :fou:
J'ai des bugs audio avec le module snd_via82xx. Bloquage sous xine, son saccadé à certain moment sur BMP.
Alors que ca marche nickel avec mon ancien 2.6.16.9
Si quelqu'un utilise le même module pour sa carte son un retour d'info serait sympa.
J'ai pas pris le temps de chercher plus --> retour en 2.6.16.9 pour ma part.

Message cité 1 fois
Message édité par rockbox le 18-06-2006 à 20:36:10

Photonium

Masse atomique : 0 uma

rockbox a écrit :

Question n'ayant pas grand rapport...
Pourquoi t'as pas attendu la version de Debian ?

Message cité 1 fois

---------------
A savoir : la dimension de Hausdorff du chou-fleur a été calculée et vaut 2.33

rockbox

Au chiotte l'équipe de France

Photonium a écrit :

Question n'ayant pas grand rapport...
Pourquoi t'as pas attendu la version de Debian ?

Je sais, je sais, mais bon des qu'un kernel sort j'aime pas attendre [:aurelie22]
Et puis j'ai jamais eu de blème avec les kernel officiel
De toute facon dès qu'il est packagé en deb je retente

Message édité par rockbox le 18-06-2006 à 20:51:54

THRAK

- THR4K -

Ya depuis quelques temps une version RC du 2.6.17 packagée dans Debian si ça te tente.

Package linux-source-2.6.17

* experimental (devel): Linux kernel source for version 2.6.17 with Debian patches
2.6.16+2.6.17-rc3-0experimental.1: all

Bon oui c'est dispo dans experimental pour l'instant, mais bon si tu n'aimes pas attendre... [:nedurb]

Message cité 1 fois
Message édité par THRAK le 19-06-2006 à 21:25:34

---------------
THRAK (def.) : 1) A sudden and precise impact moving from intention, direction and commitment, in service of an aim. 2) 117 guitars almost striking the same chord simultaneously.

dam1330

...

enfin avec le 2.6.17 compilé par mes soins, plus de de probleme de suspend to disk avec mon portable, avant j'avais les ventilo qui tournaeint a toute vringue et je perdais l'usb kan je sortais de la veille

j_c_p

Linux user

Hum, étrange la température processeur avec le 2.6.17 (par rapport au 2.6.16.20) : 57° à l'arrivée sur le bureau (et ça ne bouge que peu ensuite, genre +-1°).
Alors que si je reboote avec le 2.6.16.20, je suis à 55°C sur le bureau, puis rapidement vers les 52°C.

J'utilise powernowd (performance, donc toujours à fond) et mes paramètres sont identiques sur les deux noyaux :

2.6.17

phoenix64 src # cat /proc/cpuinfo
processor : 0
vendor_id : AuthenticAMD
cpu family : 15
model : 12
model name : AMD Athlon(tm) 64 Processor 3400+
stepping : 0
cpu MHz : 2400.000
cache size : 512 KB
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext lm 3dnowext 3dnow
bogomips : 4827.35
TLB size : 1024 4K pages
clflush size : 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management: ts fid vid ttp

phoenix64 src # cd /proc/acpi/processor/CPU0
phoenix64 CPU0 # cat power
active state: C1
max_cstate: C8
bus master activity: 00000000
states:
*C1: type[C1] promotion[--] demotion[--] latency[000] usage[00000000]
phoenix64 CPU0 # cd /sys/devices/system/cpu/cpu0/cpufreq
phoenix64 cpufreq # ls -R
.:
affected_cpus cpuinfo_min_freq scaling_cur_freq scaling_max_freq
cpuinfo_cur_freq scaling_available_frequencies scaling_driver scaling_min_freq
cpuinfo_max_freq scaling_available_governors scaling_governor stats

./stats:
time_in_state total_trans trans_table
phoenix64 cpufreq # cat cpuinfo_cur_freq
2400000
phoenix64 cpufreq # cat stats/time_in_state
2400000 36664
2200000 0
2000000 0
1800000 0
1000000 0
phoenix64 cpufreq # cat stats/trans_table
From : To
: 2400000 2200000 2000000 1800000 1000000
2400000: 0 0 0 0 0
2200000: 0 0 0 0 0
2000000: 0 0 0 0 0
1800000: 0 0 0 0 0
1000000: 0 0 0 0 0
phoenix64 cpufreq # cat stats/total_trans
0

57°

2.6.16.20

phoenix64 jcp # cat /proc/cpuinfo
processor : 0
vendor_id : AuthenticAMD
cpu family : 15
model : 12
model name : AMD Athlon(tm) 64 Processor 3400+
stepping : 0
cpu MHz : 2400.000
cache size : 512 KB
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext lm 3dnowext 3dnow
bogomips : 4831.91
TLB size : 1024 4K pages
clflush size : 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management: ts fid vid ttp

phoenix64 jcp # cd /proc/acpi/processor/CPU0
phoenix64 CPU0 # cat power
active state: C1
max_cstate: C8
bus master activity: 00000000
states:
*C1: type[C1] promotion[--] demotion[--] latency[000] usage[00000000]
phoenix64 CPU0 # cd /sys/devices/system/cpu/cpu0/cpufreq
phoenix64 cpufreq # ls -R
.:
affected_cpus cpuinfo_min_freq scaling_cur_freq scaling_max_freq
cpuinfo_cur_freq scaling_available_frequencies scaling_driver scaling_min_freq
cpuinfo_max_freq scaling_available_governors scaling_governor stats

./stats:
time_in_state total_trans trans_table
phoenix64 cpufreq # cat cpuinfo_cur_freq
2400000
phoenix64 cpufreq # cat stats/time_in_state
2400000 25157
2200000 0
2000000 0
1800000 0
1000000 0
phoenix64 cpufreq # cat stats/trans_table
From : To
: 2400000 2200000 2000000 1800000 1000000
2400000: 0 0 0 0 0
2200000: 0 0 0 0 0
2000000: 0 0 0 0 0
1800000: 0 0 0 0 0
1000000: 0 0 0 0 0
phoenix64 cpufreq # cat stats/total_trans
0

52°

Message cité 1 fois

rockbox

Au chiotte l'équipe de France

THRAK a écrit :

Ya depuis quelques temps une version RC du 2.6.17 packagée dans Debian si ça te tente.

Package linux-source-2.6.17

* experimental (devel): Linux kernel source for version 2.6.17 with Debian patches
2.6.16+2.6.17-rc3-0experimental.1: all

Bon oui c'est dispo dans experimental pour l'instant, mais bon si tu n'aimes pas attendre... [:nedurb]

Merci

anubis974

Existerais t'il un kernel qui détecte les cartes 3D NVIDIA tous seul et qui installe les pilotes !!! :ange:

Message cité 1 fois

mirtouf

Light is right !

15 et un mars avec ça ?
ça se passe au niveau de la distribution, il faut acheter une distribution commerciale.

Message cité 1 fois

---------------
-~- Libérez Datoune ! -~- Camarade, toi aussi rejoins le FLD pour que la flamme de la Révolution ne s'éteigne pas ! -~- A VENDRE

j_c_p

Linux user

Le petit dernier est là

2.6.17.1

Citation :

[PATCH] xt_sctp: fix endless loop caused by 0 chunk length (CVE-2006-3085)

Fix endless loop in the SCTP match similar to those already fixed in the
SCTP conntrack helper (was CVE-2006-1527).

gee

Bon ben hon

mirtouf a écrit :

15 et un mars avec ça ?
ça se passe au niveau de la distribution, il faut acheter une distribution commerciale.

pour 15 je t'installe les drivers si tu veux

THRAK

- THR4K -

anubis974 a écrit :

Existerais t'il un kernel qui détecte les cartes 3D NVIDIA tous seul et qui installe les pilotes !!! :ange:

Ca dépend des modèles de cartes, certaines fonctionnent très bien avec le noyau officiel et les drivers libres nv ; pour les autres, hélas certaines distributions commerciales font malheureusement le choix de distribuer les drivers proprios nvidia :fou:

De toute façon le jour où toutes les cartes nvidia seront directement supportées par le noyau officiel, il y aura deux possibilités :

- nvidia a libéré les sources de leur driver (on peut rêver, c'est pas demain la veille, etc. je sais )

- L'équipe de Linus a perdu les pédales et a choisi d'intégrer du code proprio dans le noyau :cry: : ~~GNU/~~Linux n'est alors plus un logiciel libre sous GPL, il ne reste plus qu'aux amateurs de Libre d'aller voir du côté de forks réalisés à partir des versions précédentes ou de changer de noyau (*BSD ou Hurd)

Message cité 2 fois
Message édité par THRAK le 20-06-2006 à 14:23:59

---------------
THRAK (def.) : 1) A sudden and precise impact moving from intention, direction and commitment, in service of an aim. 2) 117 guitars almost striking the same chord simultaneously.

j_c_p

Linux user

j_c_p a écrit :

L'erreur est là :

Kernel: arch/x86_64/boot/bzImage is ready (#1)
Building modules, stage 2.
MODPOST
WARNING: drivers/acpi/processor.o - Section mismatch: reference to .init.data: from .text between 'acpi_processor_power_init' (at offset 0x1017) and 'acpi_safe_halt'
CC arch/x86_64/kernel/cpufreq/acpi-cpufreq.mod.o
LD [M] arch/x86_64/kernel/cpufreq/acpi-cpufreq.ko
CC arch/x86_64/kernel/cpufreq/powernow-k8.mod.o
LD [M] arch/x86_64/kernel/cpufreq/powernow-k8.ko

edit : test du git1 en cours

Citation :

arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.c 10 + 10 - 0 !
arch/i386/kernel/cpu/cpufreq/cpufreq-nforce2.c 5 + 6 - 0 !
arch/i386/kernel/cpu/cpufreq/longhaul.c 12 + 8 - 0 !
arch/i386/kernel/cpu/cpufreq/longrun.c 0 + 1 - 0 !
arch/i386/kernel/cpu/cpufreq/powernow-k7.c 5 + 8 - 0 !
arch/i386/kernel/cpu/cpufreq/powernow-k8.c 256 + 88 - 0 !
arch/i386/kernel/cpu/cpufreq/powernow-k8.h 37 + 3 - 0 !
arch/i386/kernel/cpu/cpufreq/speedstep-centrino.c 6 + 6 - 0 !

Message édité par j_c_p le 20-06-2006 à 17:57:40

Mjules

Modérateur
Parle dans le vide

THRAK a écrit :

ou alors nouveau aura atteint son but [:volta]

---------------
Celui qui pose une question est idiot 5 minutes. Celui qui n'en pose pas le reste toute sa vie. | Membre du grand complot pharmaceutico-médico-scientifico-judéo-maçonnique.

j_c_p

Linux user

Ok, l'erreur vient bien du powernow (si je compare les logs) :

Citation :

Jun 20 18:13:15 phoenix64 powernow-k8: Found 1 AMD Athlon(tm) 64 Processor 3400+ processors (version 2.00.00)
Jun 20 18:13:15 phoenix64 powernow-k8: 0 : fid 0x10 (2400 MHz), vid 0x2
Jun 20 18:13:15 phoenix64 powernow-k8: 1 : fid 0xe (2200 MHz), vid 0x6
Jun 20 18:13:15 phoenix64 powernow-k8: 2 : fid 0xc (2000 MHz), vid 0xa
Jun 20 18:13:15 phoenix64 powernow-k8: 3 : fid 0xa (1800 MHz), vid 0xe
Jun 20 18:13:15 phoenix64 powernow-k8: 4 : fid 0x2 (1000 MHz), vid 0x12

Citation :

Jun 20 18:24:19 phoenix64 powernow-k8: Found 1 AMD Athlon 64 / Opteron processors (version 1.60.0)
Jun 20 18:24:19 phoenix64 powernow-k8: 0 : fid 0x10 (2400 MHz), vid 0x2 (1500 mV)
Jun 20 18:24:19 phoenix64 powernow-k8: 1 : fid 0xe (2200 MHz), vid 0x6 (1400 mV)
Jun 20 18:24:19 phoenix64 powernow-k8: 2 : fid 0xc (2000 MHz), vid 0xa (1300 mV)
Jun 20 18:24:19 phoenix64 powernow-k8: 3 : fid 0xa (1800 MHz), vid 0xe (1200 mV)
Jun 20 18:24:19 phoenix64 powernow-k8: 4 : fid 0x2 (1000 MHz), vid 0x12 (1100 mV)
Jun 20 18:24:19 phoenix64 cpu_init done, current fid 0x10, vid 0x2

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

Publicité

Page : 1 2 3 4 5 .. 139 140 141 .. 180 181 182 183 184 185

Page Suivante

Page Précédente

Haut de page

FORUM HardWare.fr

Linux et OS Alternatifs

Débats

[Noyau Linux] Version 6 et des brouettes

Sujets relatifs
[GNU/Linux/mdk90] Mauvaise version des kernel-headers ....... [résolu]	Le Kernel Linux
Sécuriser Linux par le Kernel : LIDS ou GRSecurity ?	[Info@ZDNet][Linux]bug kernel 2.4.20 - perte de donnée
il arrive quand le linux kernel 2.4.20 dans la Debian Sarge ?	[Linux Mandrake 9] Kernel Panic :(
une carte du kernel linux très impressionnante !!	Linux --> Kernel panic
Les 'tainted kernel' , 'no license' & cie sous linux....	Mise a jour d'un kernel, je crois que je vais abandonner linux....
Plus de sujets relatifs à : [Noyau Linux] Version 6 et des brouettes

Page générée en 0.155 secondes