Reprise du message précédent :
apparemment les drivers ati proprio ne passe pas avec la 2.6.20 ://
pas moyen de compiler ca: http://kankai.dyndns.org/logs/fglrx.log
avec le ./make.sh
 
donc évidement

 
rhaaa

un peu logique, généralement les nouvelles versions du noyal ne sont pas trop compatibles avec le module (ou le contraire ?   )
donc attends un peu, ati devrait bientôt sortir une nouvelle mouture.
 
Cela dit, j'ai un 2.6.19 et la 8.29.x tourne au petit poil chez moi

la 8.29 a jamais voulu compiler sur mon laptop lol xD (ati 9000 Mobility)
la je suis a la 8.33 sur le gros pc, elle compile plus j'attends que ati se sorte les doigts du ***
 
en attendan je peu plus jouer a tuxracer convenablement ni a supertux sans de petits acoups quelle tristesse ! pauvre de moi

 

http://forum.hardware.fr/forum2.ph [...] w=0&nojs=0

je comprends pas pour mon probleme de vmware et de la minute 30

L'API du 2.6.20 est différente des précédents, et les modules externes ont un peu de mal.

Il est arrivé chez debian: http://kernel-archive.buildserver. [...] linux-2.6/
Test dans un instant!

Hum, avec le 2.6.20, j'ai :

Mais la température de la carte graphique est ok, en revanche, je n'ai plus mes températures de disques sata (à voir si c'est relié).
 
Aussi, un message relatif à iptables :

(au boot et pas dans le dmesg, ni dans les logs, donc ça pourrait venir des scripts Gentoo et/ou de ma version 1.3.5 d'iptables).
Bon, le parefeu fonctionne cependant !
 
Quelqu'un a de mêmes warnings ?
 
edit : à noter que le pilote forcedeth a été maj entre le 2.6.19 et le 2.6.20.

Il y a eu de  changement dans NetFilter dans le noyau 2.6.20 (obligé de fouiller dans la config 1/4 h pour trouver la nouvelle config pour le nat )
De plus avec les noyau récent (2.6.19 et 2.6.20), il est fortement recommandé d'utiliser la version 1.37 de iptables qui pose pas de problème chez moi  

Oui, j'ai vu qu'il y a eu pas mal de changement (je viens de passer pas mal de temps à reluquer cela d'ailleurs, mais, j'ai peut-être oublié une option quelque part cependant).
 
Merci .
 
Je regarde aussi pour la version d'iptables.

 
Si tu utilises hhdtemp, c'est normal.
http://arch.sv.nongnu.org/archives [...] atch-7/log
 
 
En regardant les logs, j'ai vu des trucs bizarres 6 fois en moins de 2h :

mais j'ai la même chose 2 jours avants et le 9 janvier.

J'ai trouvé le coupable, c'est lilo.

regdub : en effet, j'utilise hddtemp .
-> http://bugs.gentoo.org/show_bug.cgi?id=165453
 
edit : pour iptables, j'avais oublié de valider l'option "IPv4 connection tracking support" :
 

 
Aussi, j'ai dû prendre la version de dév d'Alsa (déjà avec le 2.6.19 ) :

 
edit2 :

-> http://www.nvnews.net/vbulletin/showthread.php?t=85174

Moi aussi j'ai de gros problèmes avec internet sous le 2.6.20. Il n'y a pas iptables 1.37 chez debian, donc je vais prendre la 1.36 en croisant les doigts. Je suis sous 2.6.19 pour poster ici.
En plus j'ai un controleur SATA qui n'est plus reconnu sous 2.6.20! J'ai dû rebrancher un disque dur sur un autre contrôleur. A part ça, ça marche!  

Actuellement j'utilise un 2.6.17 sur du nForce 4 avec du PCIe et du SATA, le passage au 2.6.20 changera quelque chose ou ça ne vaut pas le coup ?

Oui, ben ça n'a rien changé Iptables 1.36. J'ai désinstallé Firestarter aussi pour voir, et internet ne marche toujours pas sous le 2.6.20. Au secours!

goldyfruit : il y a eu beaucoup de changement depuis le 2.6.17 . Rien que la nouvelle branche ATA, les majs des pilotes etc (je suis aussi en Nforce4 PCIe avec du sata, cf ma config).
 
Louvre : j'ai mis iptables 1.3.7, mais je pense plus à un souci de configuration de ton noyau, car la partie réseau du 2.6.20 est assez différente en localisation de celle du 2.6.19.

Oui, effectivement j_c_p, je viens de trouver ça sur les mailing-lists debian:
 
<Histoire de tordre le cou à toutes les rumeurs qui circulent un peu
partout :
 
Non, il n'est pas nécessaire de prendre la dernière version d'iptables,
de la recompiler ou quoi que ce soit.
 
Oui, même le paquet binaire iptables 1.2.11 inclus dans Sarge fonctionne
avec le noyau 2.6.20, et a fortiori les versions plus récentes d'Etch ou
Sid (y a pas de raison). J'ai testé.
 
Forcément, une vieille version d'iptables/ip6tables ne supportera pas
forcément toutes les fonctionnalités des derniers noyaux comme les
intervalles de port avec multiport ou le suivi de connexion IPv6 et les
autres nouvelles cibles et correspondances IPv6. Mais ce qui marchait
avec un noyau précédent doit continuer à marcher.
 
Qu'est-ce qui a changé dans Netfilter du noyau 2.6.20 ? L'ajout du NAT
et de la prise en charge des protocoles "spéciaux" par la nouvelle
infrastructure de suivi de connection nf_conntrack. nf_conntrack est une
infrastructure de suivi de connexion indépendante de la couche 3,
supportant IPv4 et IPv6, destinée à remplacer l'infrastructure
ip_conntrack héritée du noyau 2.4 qui ne supporte que IPv4. Lors de son
introduction dans le noyau 2.6.15, nf_conntrack ne supportait pas encore
le NAT et très peu de protocoles spéciaux (FTP et SCTP), donc le vieil
ip_conntrack, seul capable de faire du NAT, restait le choix par défaut.
Maintenant, nf_conntrack gère le NAT en IPv4 (il n'y aura probablement
jamais de NAT pour IPv6) et les mêmes protocoles spéciaux que
ip_conntrack (FTP, TFTP, IRC DCC, PPTP, SIP, H.323...) donc il peut
totalement le remplacer. Néanmoins les deux versions du suivi de
connexion et NAT, mutuellement exclusives, cohabitent encore pour un
temps dans les sources du noyau et ont donc des noms d'options
différents. Quand on passe de l'un à l'autre, il faut resélectionner des
options pour les différentes fonctions. Pour ne rien arranger, make
oldconfig semble sélectionner par défaut nf_conntrack et désélectionne
les options associées à ip_conntrack dans l'ancienne configuration.
C'est pourquoi si on ne fait pas attention à balayer les options des
sous-menus Netfilter avec make menuconfig|xconfig|gconfig, on risque de
se retrouver avec des fonctions comme le NAT absentes.
 
J'ai compilé deux versions du noyau 2.6.20, une avec ip_conntrack et une
avec nf_conntrack, en prenant soin d'activer toutes leurs options, et
les deux fonctionnent avec iptables de Sarge.
 
Conclusion : vérifiez vos options de compilation de Netfilter.>>
 
 
Mais je n'ai jamais recompilé de noyau. Est-ce que ça veut dire que des millions de linuxiens qui ne l'ont jamais fait non plus vont être obligés de le faire? Linux s'est complètement planté sur ce coup là ou quoi?

Merci pour cette belle explication .
Sinon, bah, depuis le 2.6.19, il y a des changements importants (l'ATA, et là la partie filtrage), donc, soit tu fouilles bien pour activer ce qu'il te faut, soit tu attends gentillement le noyau pour ta distribution (enfin, sur Gentoo, ça reste en manuel ).
 
De toute façon les patchs de sécurité sont backportés par les mainteneurs des distributions (ensuite pour les nouvelles fonctionnalités, c'est autre chose, mais c'est également faisable et fait dans certains cas).
 
edit : mon lsmod du 2.6.20 ->

 
Ben en fait mon 2.6.20 provient d'un dépôt debian experimental. Donc ça veut dire que je dois attendre une prochaine version de ce kernel dans ce même dépôt qui règlera le problème. Peut-être...

Ah ok, c'est possible alors .
Sinon, j'ai mis mon lsmod, si ça peut aider.

 
Oui, merci! Je viens de faire un lsmod de mon 2.6.19, et je vais rebooter sous 2.6.20 pour comparer. En bas de cette discussion ils parlent de ce qu'il faut changer dans les options de compil: https://linuxfr.org/2007/02/05/21986.html

Bon ben je vais compiler tout ça alors.
Merci.

Louvre : j'avais commencé à regarder la news sur linuxfr hier, mais je n'ai pas tout lu (on verra ce soir là). De rien sinon.
 
goldyfruit : pas de quoi (et ça va être un peu chaud de partir du 2.6.17, vu les changements depuis, mais en prenant sont temps, pas de souci à mon avis).
 

Alors voilà tout les modules qui ont disparu lors du passage au 2.6.20:
ipt_MASQUERADE
ip_nat
ip_conntrack_irc
ip_conntrack_ftp
xt_state
ip_conntrack  (49652  5 ipt_MASQUERADE,ip_nat,ip_conntrack_irc,ip_conntrack_ftp,xt_state)
nfnetlink  (6616  2 ip_nat,ip_conntrack)

Pour quelle raison ?

La version 1.0.13 ne compilait pas .
 
edit : on peut remarquer que les paquets Gentoo étaient prêts aussi (ça l'avait déjà fait pour la sortie du 2.6.19).

http://gentoo-portage.com/media-so [...] eLog#ptabs

en moyenne combien de temps met ces fégniasses de chez ati pour faire une nouvelle version du driver ?

Un driver ATI sort tous les mois (ou 2 mois) environ il me semble.

et comme le dernier date du 11/01/07 on devrait en avoir un nouveau d'ici un jour ou deux !

c'est normal si des drivers récents de ati ne fonctionne pas avec la 9000 mobility ?
car la version qu'il me propose pour cette carte est tellement ancienne qu'elle refuse même de compiler avec un kernel 2.6.19.2
 
du coup je suis sans DRI sur mon laptop ce qui est pluttot enyeux pour jouer a supertux qui a tendance a raccrocher dessus...

la 9000 mobility possède un pilote libre

La mise à jour ne c'est pas super bien passée.  
Au reboot de la machine quand je choisi le 2.6.20 dans Grub, celui-ci me retourne ce message :

 
Qu'ai-je oublié ?
Merci.

ah bon ?, c'est quoi le nom du dit pilote ?
je verais bien si je peu tenter ma chance, je n'ai rien a perdre après tout

radeon il me semble

je tente, je vien d'activer le DIRECT RENDERING MANAGER dans le noyau aussis avan de recompiller, en vérifiant que j'ai bien activé les suport de carte ati

je viens de tenter, ca me parais quand même bizzard:
glxinfo | grep rendering me retourne "no"
mais en terme de performances c'est comme si c'était a true mis a part pour glxgears
 
je m'explique: glxgears est TRES lent mais le cpu peu utilisé, de meme que quand j'ai tenté un supertux avec opengl le cpu était moin de 10% sans ramer du tout cette fois ci
étrange non ?

tu as bien chargé le dri ? mis le bon pilote ?

vivi le load "dri" est bien present, et le pilote est bien a driver "radeon"

si tu avait installé les pilotes ATI précédemment, tu as bien remis la libgl mesa ?

Incroyable!    
Je suis sous le 2.6.20!    
Un nouveau deb est arrivé aujourd'hui: http://kernel-archive.buildserver. [...] linux-2.6/
Il pèse 400 Ko de plus que celui d'avant-hier, et au bout de plusieurs "dhclient" dans une console root, internet a fini par fonctionner!