mardi 30 juin

Accueil :: Dépêches :: Entretiens :: Journaux :: Forums :: Sondages :: Suivi :: Statistiques :: Contact :: Plan

Articles précédents : Logiciel

Liens connexes

Changelog 2.6.9 (985 hits)
télécharger le 2.6.9 (669 hits)
lien direct vers un miroir en france (476 hits)
Le patch pour nVidia (1144 hits)

Dépêche modérée par

fatnerf

Dépêche éditée par

Logiciel : Sortie du noyau Linux 2.6.9

Posté par Colin Leroy (page perso, ). Modéré le 19 octobre 2004.

Linux 2.6.9 est sorti hier, le 18 octobre.

Entre 2.6.8 et 2.6.9, il y a beaucoup de différences, qui représentent beaucoup de petites choses :
mises à jour de différentes architectures (Sparc, PPC, ARM), ACPI, i2c, USB, systèmes de fichiers, pilotes vidéo et réseau...

ALSA a bénéficié d'une mise à jour massive, grâce à une synchronisation avec leur CVS; les vérifications de types sont maintenant plus strictes (d'où l'augmentation du nombre de warnings à la compilation - corrigez-en!) et pas mal d'annotations ont été ajoutées (elles permettent d'identifier correctement ce qui vient de l'espace utilisateur et ce qui vient du noyau, afin d'éviter que le noyau patouille dans les données utilisateur).

Changelog 2.6.9 (985 hits)
télécharger le 2.6.9 (669 hits)
lien direct vers un miroir en france (476 hits)
Le patch pour nVidia (1144 hits)

> Lire la suite (40 commentaires, moyenne: 2,6). [dépêche : 564 caractères]

Cette version apporte donc beaucoup de nettoyages et quelques fonctionnalités supplémentaires (notamment dans ALSA, mais aussi quelques unes dans différents pilotes).

Certains utilisateurs pourront se rendre compte que les pilotes nVidia sont (encore) cassés, un patch est disponible.

À noter que le Changelog est pour l'instant incomplet, mais Linus Torvalds va le corriger pour qu'il couvre l'intégralité des changements depuis 2.6.8.

À noter aussi que le patch-2.6.9 disponible sur kernel.org est un patch du 2.6.8 au 2.6.9 et non du 2.6.8.1 au 2.6.9.

Cette discussion est archivée, il n'est plus possible de laisser des commentaires.

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.

Quelques corrections assez importantes

Posté par Brice Arnould ( un_brice ) (page perso, ) le 19/10/2004 à 18:53. (lien). Évalué à 6.

Une faille de sécurité (pas énorme) à été corrigée au passage.

[PATCH] security issue in firmware system

The firmware loader has a security issue. Firmware on some devices can
write to all memory through DMA. Therefore the ability to feed firmware
to the kernel is equivalent to writing to /dev/kmem. CAP_SYS_RAWIO is
needed to protect itself.

[ Editors note: the firmware file is 0644, and owned by root, so this
"security issue" is really only an issue for people who use
capabilities explicitly, rather than the regular Unix permissions.
This patch makes it do the same checks we do for /dev/mem etc. ]

(au passage, il feraient mieux de prendre l'habitude de les anoncer plus lisiblement que dans le changelog, surtout qu'il y a eu quelques cas très douloureux y'a pas si longtemps).

Ainsi qu'une autre mise à jour critique de corruption des paquets UDP mais seulement pour "Linux en mode utilisateur".

--
Respect à RMS.

[^]Re: Quelques corrections assez importantes
Posté par 007 () le 19/10/2004 à 20:24. (lien). Évalué à 5.
> au passage, il feraient mieux de prendre l'habitude de les anoncer plus lisiblement que dans le changelog

Le Linux vanilla n'est plus un noyau pour la production. Ou uniquement pour les personnes abonnées à la lkml et qui comprennent ce qui s'y dit.

C'est lié au nouveau modèle de développement défini durant le dernier sommet noyau :
http://lwn.net/Articles/94386/(...)
Un autre article qui parle de la même chose :
http://lwn.net/Articles/95312/(...)

À lire attentivement avant de protester.
- [^]Re: Quelques corrections assez importantes
  
  Posté par Colin Leroy (page perso, ) le 19/10/2004 à 20:41. (lien). Évalué à 2.
  Le Linux vanilla n'est plus un noyau pour la production. Ou uniquement pour les personnes abonnées à la lkml et qui comprennent ce qui s'y dit.
  
  Exagéré, pour le moins.
  
  let the distributors do the final stabilization work. In his vision of the future, the kernel.org kernel will be the most featureful and fastest kernel out there, but it will not necessarily be the most stable.
  
  Il faut lire stable au sens stabilité des interfaces, APIs et tout ça, pas au sens ça va m'exploser à la figure à chaque branchement de périphérique USB.
  
  --
  Claws Mail - it bites!
  - [^]Re: Quelques corrections assez importantes
    Posté par 007 () le 19/10/2004 à 21:38. (lien). Évalué à 1.
    > Il faut lire stable au sens stabilité des interfaces
    
    Non.
    Au sens ou la stabilité/sécurité n'est pas la priorité. C'est pris en compte, mais ce n'est pas la priorité. Si tel ou tel driver sucks ou s'il y a un trou de sécurité : tant pis. Tu peux attendre plusieurs semaines avant d'avoir un noyau vanilla avec un fix de sécurité (c'est déjà arrivé plusieurs fois !).
    
    Relis bien :
    http://lwn.net/Articles/94386/(...)
    Ça me parait claire. Si t'as un serveur en production et met à jour vers Linux 2.6.n+1, ça peut ne pas marcher entre autre à cause d'incompatibilité. Mais évidemment que le noyau vanilla marchera sur la plus part des configurations. Sinon comme ils font les développeurs pour bosser :-)
    - [^]Re: Quelques corrections assez importantes
      
      Posté par Cali_Mero () le 19/10/2004 à 21:49. (lien). Évalué à 1.
      Non.Au sens ou la stabilité/sécurité n'est pas la priorité.
      
      Ben si, c'est exactement ce qu'il dit....
      
      --
      #define MAGIC 0xdefaced /* I should've patented this number -cliph */
      - [^]Re: Quelques corrections assez importantes
        
        Posté par 007 () le 19/10/2004 à 22:17. (lien). Évalué à 1.
        > Ben si, c'est exactement ce qu'il dit....
        
        Oui, il a raison, :
        - "pas au sens ça va m'exploser à la figure à chaque branchement de périphérique USB."
        
        Effectivement, ça ne va pas exploser à la figure à chaque branchement de périphérique USB. C'est aussi bien qu'un 2.5.
        
        Questions :
        C'est bien qu'une machine en production ait les sécurités fix bien après les autres ?
        C'est bien qu'une mise à jours (peut-être avec sécurité fix) soit incompatible avec la version production ?
        
        Si pour toi ça aussi ça te parait adapté pour la production...., je ferme ma gueule. J'ai des exigences qui n'ont manifestement plus cours.
        
        [^]Re: Quelques corrections assez importantes
        
        Posté par Colin Leroy (page perso, ) le 20/10/2004 à 06:34. (lien). Évalué à 3.
        Effectivement, ça ne va pas exploser à la figure à chaque branchement de périphérique USB. C'est aussi bien qu'un 2.5.
        
        T'as pas dû essayer beaucoup de 2.5. C'est incomparable. Le 2.5.69 bootait avec 11472.3 jours d'uptime sur ppc, par exemple...
        
        C'est bien qu'une machine en production ait les sécurités fix bien après les autres ?
        C'est bien qu'une mise à jours (peut-être avec sécurité fix) soit incompatible avec la version production ?
        
        C'est pour ça que les gens qui font des choses sérieuses utilisent le noyau de leur distribution. Ils font ça depuis très longtemps, entre nous. Depuis bien avant le "nouveau" modèle de développement qui n'est que l'officialisation de ce qui se passait déjà avant.
        
        --
        Claws Mail - it bites!
        
        [+] [^]Re: Quelques corrections assez importantes
        
        Posté par 007 () le 20/10/2004 à 07:37. (lien). Évalué à -1.
        T'es très claire.........................
        
        > des choses sérieuses
        
        La production n'est pas une "chose sérieuse" ?
        
        > Depuis bien avant le "nouveau" modèle de développement qui n'est que l'officialisation de ce qui se passait déjà avant.
        
        C'est ce qui est dit dans les url données. Mais il faut faire attention avec toi car tu as sûrement un "avant" et un "avant". C'est le nouveau modèle pour Linux >= 2.6 . L'url donnée ne dit pas que c'est le nouveau modèle pour Linux >= 2.6.9 .
        
        Pour ton info, Linux 2.4 était la précédente branche stable. Donc avant, par rapport à 2.6, ce n'était pas comme maintenant.
        
        [^]Re: Quelques corrections assez importantes
        
        Posté par Colin Leroy (page perso, ) le 20/10/2004 à 08:52. (lien). Évalué à 2.
        La production n'est pas une "chose sérieuse" ?
        
        C'est de ça dont je parle. T'es bouché, un peu, non?
        
        Pour ton info, Linux 2.4 était la précédente branche stable. Donc avant, par rapport à 2.6, ce n'était pas comme maintenant.
        
        Je pense à "avant" dans le sens < 2.6. Pour ton info, je suis au courant pour le 2.4. Je suis aussi au courant qu'avant encore il y avait le 2.2, etc.
        
        --
        Claws Mail - it bites!
        
        [^]Re: Quelques corrections assez importantes
        
        Posté par 007 () le 20/10/2004 à 10:05. (lien). Évalué à 1.
        Je veux bien admettre que tu es particuliairement heureux avec Linux 2.6 vanilla en production (comme certainement beaucoup de personnes), mais là ce sont des mainteneurs du noyau qui disent qu'il y a changement.
        Ils ont tords aussi car ils n'ont pas ton niveau d'"expertise" ?
        C'est le rédacteur de lwn qui affabule ?
        
        Fais moi une explication de texte.
  - [^]Re: Quelques corrections assez importantes
    
    Posté par reno () le 20/10/2004 à 05:18. (lien). Évalué à 5.
    Stable au sens stabilité des interfaces?
    
    Mouai, le fait de devoir utiliser cdrecord avec le setuid bit maintenant, ce n'est pas tres "stable" comme interface, mais j'admets que c'est "presque stable" *cough*.
    
    Et puis je crois que recemment il y avait une fuite mémoire lors de la gravure d'un CD justement, alors certes ça n'explose pas lors du branchement d'un périphérique USB mais..
    
    D'un autre coté le 2.4 marche bien alors il y a peu de raison d'etre presser de passer en 2.6..
    - [^]Re: Quelques corrections assez importantes
      
      Posté par Colin Leroy (page perso, ) le 20/10/2004 à 06:36. (lien). Évalué à 3.
      Et puis je crois que recemment il y avait une fuite mémoire lors de la gravure d'un CD justement
      
      Ça c'est ce qu'on appelle un gros bug, comme le coup du NFS qui a motivé la sortie du 2.6.8.1. Ça n'a rien à voir avec le "nouveau modèle de développement", c'est un bug qui serait arrivé de toutes façons...
      
      --
      Claws Mail - it bites!
      - [^]Re: Quelques corrections assez importantes
        
        Posté par lezardbreton (Jabber id, page perso, ) le 20/10/2004 à 07:49. (lien). Évalué à 0.
        Je ne pense pas. Avec l'ancien mode de développement du noyau, on aurait eu un 2.6.8.2 à mon avis.
        
        [^]Re: Quelques corrections assez importantes
        
        Posté par 007 () le 20/10/2004 à 13:18. (lien). Évalué à 1.
        w.x.y.z : le z est pour les distributeurs, etc...
        Linus c'est fait remonté les bretelles pour le 2.6.8.1 (qui a été qualifié de "fiasco" pour le nom) et il a "promis" de ne plus recommencer pour une release officielle.
        D'ailleur le patch du 2.6.9 est basé sur un 2.6.8 et non sur un 2.6.8.1. Ceux qui ont un 2.6.8.1 doivent faire un "downgrade" avant d'appliquer le patch.
        
        > Avec l'ancien mode de développement du noyau
        
        On aurait un 2.6.9 à la place de 2.6.8.1. J'avais EXTRAVERSION n'avait été utilisé pour une release officiel sauf pour le 2.6.8.1.
        
        [^]Re: Quelques corrections assez importantes
        
        Posté par lezardbreton (Jabber id, page perso, ) le 20/10/2004 à 13:59. (lien). Évalué à 2.
        Exact, ce que je voulais dire exactement, c'est qu'avec l'ancien mode de développement, on aurait eu des corrections sur des versions stables, et donc un 2.6.9 pour la correction NFS, puis un 2.6.10 pour la correction du problème de gravure. Ceci au lieu de laisser trainer des versions 'stables' avec des bugs/failles à corriger par patch comme actuellement.
      - [^]Re: Quelques corrections assez importantes
        
        Posté par reno () le 20/10/2004 à 13:09. (lien). Évalué à 4.
        > Ça c'est ce qu'on appelle un gros bug, comme le coup du NFS qui a motivé la sortie du 2.6.8.1. Ça n'a rien à voir avec le "nouveau modèle de développement", c'est un bug qui serait arrivé de toutes façons...
        
        Bin si un peu quand meme: le systeme des "release candidate" est sens'e attraper ce genre de bug trivial a detecter, mais j'ai comme l'impression que comme ils ont decid'e que c'etait au distrib de stabiliser le kernel, ils vont parfois un 'peu vite' : sur une branche stable, livrer "quand ca compile", ca fait quand meme un poil desordre..
- [^]Re: Quelques corrections assez importantes
  
  Posté par Ramso (page perso, ) le 20/10/2004 à 10:15. (lien). Évalué à 2.
  > Le Linux vanilla n'est plus un noyau pour la production.
  
  De toute façon, qui aurait l'idée de mettre un noyau Vanilla dès qu'il sort ? Les éditeurs font le travail de packaging et il faut laisser le temps de tester.
  
  Bon bien sûr y'a les gentooïstes qui font leurs ports vite fait, comme si c'était critque de l'avoir le soir même... mais qui aurait l'idée de mettre et maintenir une Gentoo en production ?
  
  --
  Groar !
  - [^]Re: Quelques corrections assez importantes
    
    Posté par 007 () le 20/10/2004 à 13:07. (lien). Évalué à 2.
    > Bon bien sûr y'a les gentooïstes qui font leurs ports vite fait
    
    J'ai testé une Gentoo assez longuement et cette distribution m'a "bluffée" par sa qualité globale compte tenu de ses objectifs (dont je ne suis pas fou mais c'est une autre histoire).
    Le noyau par défaut (stable, c-à-d USE="x86") est un 2.4.
    Le noyau en développement (USE="~x86") est un 2.6 et a les patchs de sécurité/fix "qui vont bien".
    
    Il faut bien tester les nouveaux noyaux. Que ce soit en parti fait pas les "gentooïstes" ne me dérange en rien.
    
    Tiens, il y a Linux 2.6.9 dans Rawhide (Fedora). Chiao, je m'en vais tester tout ça.
    - [^]Re: Quelques corrections assez importantes
      
      Posté par 007 () le 20/10/2004 à 13:21. (lien). Évalué à 1.
      > USE="x86"
      
      Ooops, c'est KEYWORDS="x86". Ou un truc comme ça, je n'ai plus de Gentoo pour vérifier.
  - [^]Re: Quelques corrections assez importantes
    
    Posté par Mathieu Pillard (page perso, ) le 22/10/2004 à 03:06. (lien). Évalué à 2.
    Chez gentoo, les paquets vanilla-sources / developpement-sources est mis a jour assez rapidement, oui, mais:
    - pas forcement en stable, sauf maj de sécu.
    - ce n'est pas le kernel "officiel" et par défaut, simplement un parmis ceux que on te propose
    
    Je sais que ca va te surprendre, mais oui, gentoo fait un travail de packaging et laisse le temps de tester.
    
    (NB pour le commentaire a coté: c'est ACCEPT_KEYWORDS.)

[^]Re: Quelques corrections assez importantes

Posté par Cali_Mero () le 19/10/2004 à 20:31. (lien). Évalué à 8.
Ainsi qu'une autre mise à jour critique de corruption des paquets UDP mais seulement pour "Linux en mode utilisateur".

Pour les anglophobes qui ne tiltent pas, il s'agit de User-Mode Linux (UML), le patch de virtualisation de système (un noyau maître permettant de faire tourner plusieurs noyaux fils totalement isolés les uns des autres, partageant les ressources de la machine hôte), qui est une alternative à VServer.

http://www.usermodelinux.org/(...)

--
#define MAGIC 0xdefaced /* I should've patented this number -cliph */

Possibilité d'inclure DSDT perso

Posté par ginkyo (page perso, ) le 19/10/2004 à 19:14. (lien). Évalué à 4.

**Include Custom DSDT
(/boot/dsdt_perso.hex) Custom DSDT Table file to include
Pensez à mettre la version hexa et pas DSDT.aml

Rappel pour ceux et celles qui ont des prob d'ACPI c'est plutôt simple :
cat /proc/acpi/dsdt >dsdt_o.aml ou bien acpidmp DSDT > dsdt_o.aml
iasl -d dsdt_o.aml Dé-assemble AML vers ASL
cp -a dsdt_{o,perso}.dsl
../iasl -tc dsdt_perso.dsl produit dsdt_perso.hex et DSDT.aml
corriger le dsdt_perso.dsl en fx des erreurs voir http://www.unix.privat.t-online.de/acpi.html(...)

**Nous avons maintenant la possiblité d'avoir plus d'infos de débogue sur l'acpi, pourquoi ne pas inclure les bonnes ACPI_DEBUG dans les méthodes du dsdt_perso.dsl qui ne fonctionne pas (par exmple la _WAK) ? (perso je n'ai pas fait, je me suis pas encore plongé dans l'asl)

(ordi portable clevo 5820D vendu/recommandé par keynux !)
Perso je n'ai pas la chance d'avoir, une gestion d'énergie correcte :
- même corrigé, mon ventilo tourne au max et obligé de mettre acpi=force
- même en 300Mhz (au lieu de 2,4GHZ) le proc chauffe et le ventilo tourne au max
- Aucunes fonctions de régulations du ventilo dans la dsdt :((
- réguler le proc avec l'acpi ne fonctionne pas (ACPI Processor P-States driver)

Mes conseils
Si un jour je me rachète un ordi portable, je lui balancerai une knoppix avec un iasl, et hop un petit iasl -tc dsdt_perso.dsl pour voir
- si la table est boggué

vi dsdt_perso.dsl :
- voir si le fichier contient une idiotie du style If (LEqual (SizeOf (_OS), 0x14)) (ou 0x27) > conditions pour les SE qui ont 20 charactères : Ms win encore eux !
- voir si le code contient des méthodes pour FAN1 et FAN2

Voir aussi si dsdt_o.aml contient dans l'entête MSFT (compilé avec cette saloperie de compilateur de Microsoft )

L'informatique c'est vraiment pas pour moi, j'ai jamais de chance avec mes ordis (mais c'est aussi pour ça que j'ai appris bcp)

--
« Si quis scienter in tantum a vino abstineret ut naturam multum gravaret a culpa immunis non esset. »Saint Thomas d'Aquin, Somme théologique, II-II, 150, 1 ad 1.

[^]Re: Possibilité d'inclure DSDT perso

Posté par ginkyo (page perso, ) le 19/10/2004 à 19:16. (lien). Évalué à 10.
DSDT : Differentiated System Description Table
dsdt.dat : version binaire de la table DSDT
ASL : ACPI Source Language (code source)
AML : ACPI Machine Language (binaire) (utilisé par le micrologiciel ou le SE
ACPICA : ACPI Component Architecture
iASL : compilateur de ASL en AML, peut aussi dé-assembler l'AML
(collé de mon aide mémoire)

--
« Si quis scienter in tantum a vino abstineret ut naturam multum gravaret a culpa immunis non esset. »Saint Thomas d'Aquin, Somme théologique, II-II, 150, 1 ad 1.

[^]Re: Possibilité d'inclure DSDT perso

Posté par Matthieu C () le 19/10/2004 à 20:37. (lien). Évalué à 2.
Avant c'etait aussi possible en l'incluant directement lors de la compilation.

Maintenant il serait capable de le recuperer dans /boot, ca ma l'air effectivement mieux.

T'as un lien sur cette nouvelle fonctionalite (je n'ai rien trouve dans Documentation/ ) ?
- [^]Re: Possibilité d'inclure DSDT perso
  
  Posté par Matthieu C () le 19/10/2004 à 20:41. (lien). Évalué à 2.
  hum, je viens de regarder les sources et toujours pas de chargement dynamique, c'est juste le hack qui permettait de les charger qui a ete inclu...
  - [^]Re: Possibilité d'inclure DSDT perso
    
    Posté par Mathieu Pillard (page perso, ) le 19/10/2004 à 22:15. (lien). Évalué à 2.
    Pour ceux que ca interesse, le chargement dans un initrd (fort pratique ma foi), c'est par ici: http://gaugusch.at/kernel.shtml(...)
    
    Certaines distros incluent ca de base, la page mentionne suse et mandrake, quelqu'un peut confirmer ou en ajouter d'autres ?
    - [^]Re: Possibilité d'inclure DSDT perso
      
      Posté par Raphaël Gertz (Jabber id, page perso, ) le 20/10/2004 à 10:42. (lien). Évalué à 1.
      je confirme pour l'utilisation dans un initrd pour mandrake par contre c'est un sacré bordel al régénération de l'initrd sous mdk, j'ai pas pris le temps de lire le script pour l'instant, surtout qu'il y mettent aussi des images pour le bootsplash et autres amélioration graphique...
      
      --
      site perso : http://rapsys.free.fr/

alsa ?

Posté par ploum (page perso, ) le 19/10/2004 à 19:18. (lien). Évalué à 2.

Quelqu'un a plus d'infos concernant les changements dans Alsa ? J'aimerais savoir si ma carte Nforce2 intel8x0 sera mieux supportée (actuellement, je peux pas régler le volume et les applis doivent utiliser l'émulation OSS, le ALSA direct plantant)

Sinon, j'attend toujours que ma carte graphique (une geforce2MX) supporte le frame-buffer :-(

[^]Re: alsa ?

Posté par Oni (Jabber id, page perso, ) le 19/10/2004 à 20:22. (lien). Évalué à 2.
Ben déjà pour le frame-buffer, il faut utiliser VESA et non celui pour les Nvidia Riva...
Sinon moi j'ai aucun problème grave avec le chip audio Nforce 2 et Alsa...

[^]Re: alsa ?

Posté par Matthieu C () le 19/10/2004 à 20:33. (lien). Évalué à 2.
Au passage y a des deadlock dans les drivers alsa avec le nouvel module-init-tools ...
Ne fait pas comme moi un script dans /etc/init.d/ qui charge les soundfont midi, sinon vous riquez d'attendre longtemps ;)

[^]Re: alsa ?

Posté par Colin Leroy (page perso, ) le 19/10/2004 à 20:38. (lien). Évalué à 3.
Sinon, j'attend toujours que ma carte graphique (une geforce2MX) supporte le frame-buffer :-(

man vi, man gcc :-)

Sérieusement, c'est un projet de quelques semaines pour un non-professionnel de la programmation noyau. La plupart du code est "facile" à écrire en prenant exemple sur un autre driver framebuffer et en dégottant les trucs spécifiques dans le driver nv de Xorg... (d'où rivafb vient tout droit, apparemment - d'après les commentaires dans drivers/video/riva/*c)

--
Claws Mail - it bites!

[^]Re: alsa ?

Posté par newbix (page perso, ) le 20/10/2004 à 16:46. (lien). Évalué à 1.
J'utilise ALSA avec le 2.6.8.1 sur ma carte mère nForce2 (Shuttle SN45G) et ça marche comme un charme, y compris en 5.1 et avec le mixing software (dmix).

Je vais essayer le 2.6.9 ce soir si j'ai le temps.

Il n'y a pas que Alsa :-)

Posté par 007 () le 19/10/2004 à 21:19. (lien). Évalué à 8.

Selon lwn :
- a lot of NTFS updates
- block I/O barrier support ( http://lwn.net/Articles/103183/(...) )
- patch allowing unprivileged process to lock small amounts of memory in RAM

http://lwn.net/Articles/96587/(...)

- new USB storage driver
- cluster-wide file locking infrastructure
- completely out-of-line spinlocks ( http://lwn.net/Articles/97537/(...) )
- AMD dual-core support
- support for the POSIX waitid() system call
- KProbes ( http://www-124.ibm.com/linux/projects/kprobes/(...) )
- USB "on the go" support
- the "flex mmap" user-space memory layout
- m32r architecture support ( http://www.linux-m32r.org/(...) )
- a bunch of latency-reduction work (Ingo Molnar)
- Nouvelle adressage mémoire : http://lwn.net/Articles/91829/(...)
- new I/O memory access mechanism ( http://lwn.net/Articles/102232/(...) )
- and lots of fixes :-)

Après le Kernel coding style, il y a maintenant le "Linux kernel management style" :
http://lwn.net/Articles/105375/(...)

Merci à lwn.

Corruption avec gcc 3

Posté par j () le 19/10/2004 à 22:27. (lien). Évalué à 3.

Attention si vous utilisez gcc 3, Richard B. Johnson a remarqué que certaines instabilités ou corruptions des données pouvaient être liées à un bogue de gcc 3. Le kernel 2.6.9 est aussi concerné :

http://00f.net/blogs/index.php/2004/10/20/register_corruption_with_(...)

[^]Re: Corruption avec gcc 3

Posté par maher b (page perso, ) le 20/10/2004 à 05:04. (lien). Évalué à 2.
d'après Linus Torvalds il sagit effectivement d'un problème de compilateur, mais affirme cependant n'avoir aucun problème avec ses versions de gcc:

"Heh. Clearly there's a gcc bug.. What compiler version?

I've got gcc-3.2 and gcc-3.3, and neither seems to have any trouble, but
hey, I'm cursed by having fairly up-to-date systems.

That said, I know what's up, but it would be good to know what compilers
have this problem.."

http://kerneltrap.org/node/view/4026(...)

histoire aussi de comparer le nombre des différents warnings entre les versions de la branche 2.6 avec gcc 3.2.2 vous pouvez jetter un coup d'oeil sur ce lien:

http://developer.osdl.org/cherry/compile/(...)

Patch grsec ou equivalent

Posté par FRLinux (page perso, ) le 20/10/2004 à 10:25. (lien). Évalué à 2.

Bon, sachant que le site de GRsecurity ne va pas sortir de patch GRsec pour 2.6.{8,9}.x, quelqu'un aurait-il une bonne adresse pour un patch de sécurité sur kernel 2.6 ?

Merci,
Steph

[^]Re: Patch grsec ou equivalent

Posté par j () le 20/10/2004 à 12:51. (lien). Évalué à 0.
http://www.openbsd.org(...) ? :)

Graveur SCSI

Posté par Vincent Ternisien () le 20/10/2004 à 17:46. (lien). Évalué à 1.

J'ai beaucoup de probleme avec le noyau 2.6.8.1 avec une Fedora 2 pour graver :(

Je doit utiliser, en root, un console avec les programmes mkisofs/cdrecord et encore, ca ne passe pas a chaque fois.
J'ai finit par arreter le _gravationnage_ sous Linux et je doit repasser sous Window$ pour ne pas casser tous mes cdr(w).

Quelqu'un a t'il des informations les graveurs SCSI avec le 2.6.9 ?

[^]Re: Graveur SCSI

Posté par 007 () le 20/10/2004 à 18:11. (lien). Évalué à 2.
> Je doit utiliser, en root

Normal :
http://lwn.net/Articles/98379/(...)

Pour le reste, j'ai entendu parlé de quelques problèmes qui doivent être corrigés.
Avec la dernière FC3T3 je peux graver sans être root et sans suid pour cdrecord (graveur IDE).

> avec une Fedora 2

Il y aura _peut-être_ une mise à jour pour FC2 après la sortie de FC3.

Kernel 2.6.9 ? Yes ! Mais ...

Posté par Gaeldîr (page perso, ) le 26/10/2004 à 00:06. (lien). Évalué à 0.

Hmm ... Je tourne sous le Kernel 2.6.9 sur mon portable depuis samedi soir ... Ha çà y a pas, c'est un excellent kernel : c'est stable, mon proc (un Pentium-M 715 alias "Dothan 1.5 GHz") est bien reconnu, c'est bien le speedstep avec le démon PowerNowD !

MAIS il y a un truc qui me choque : ils ont viré le supermount !
Comment je fais moi, maintenant, avec ma clef USB, sans supermount, sachant qu'avec submount, si je lance submountd, j'ai doit au message "submountd: 1 argument received, 6 needed." ?

Comment je fais, hm, pour utiliser ma clef USB avec le kernel 2.6.9 ?

Ils se seraient pas un peu ch*é dessus, Linus et les autres, en enlevant le supermount du kernel 2.6.9 ? :)

--
Ubuntu/Debian ... definitively !

Revenir en haut de page

Articles précédents : Logiciel

Liens connexes

Dépêche modérée par

Dépêche éditée par

Logiciel : Sortie du noyau Linux 2.6.9

Quelques corrections assez importantes

[^]Re: Quelques corrections assez importantes

[^]Re: Quelques corrections assez importantes

[^]Re: Quelques corrections assez importantes

[^]Re: Quelques corrections assez importantes

[^]Re: Quelques corrections assez importantes

[^]Re: Quelques corrections assez importantes

[+] [^]Re: Quelques corrections assez importantes

[^]Re: Quelques corrections assez importantes

[^]Re: Quelques corrections assez importantes

[^]Re: Quelques corrections assez importantes

[^]Re: Quelques corrections assez importantes

[^]Re: Quelques corrections assez importantes

[^]Re: Quelques corrections assez importantes

[^]Re: Quelques corrections assez importantes

[^]Re: Quelques corrections assez importantes

[^]Re: Quelques corrections assez importantes

[^]Re: Quelques corrections assez importantes

[^]Re: Quelques corrections assez importantes

[^]Re: Quelques corrections assez importantes

[^]Re: Quelques corrections assez importantes

Possibilité d'inclure DSDT perso

[^]Re: Possibilité d'inclure DSDT perso

[^]Re: Possibilité d'inclure DSDT perso

[^]Re: Possibilité d'inclure DSDT perso

[^]Re: Possibilité d'inclure DSDT perso

[^]Re: Possibilité d'inclure DSDT perso

alsa ?

[^]Re: alsa ?

[^]Re: alsa ?

[^]Re: alsa ?

[^]Re: alsa ?

Il n'y a pas que Alsa :-)

Corruption avec gcc 3

[^]Re: Corruption avec gcc 3

Patch grsec ou equivalent

[^]Re: Patch grsec ou equivalent

Graveur SCSI

[^]Re: Graveur SCSI

Kernel 2.6.9 ? Yes ! Mais ...