Reprise du message précédent :

 
sans doute qu'avec le patch mm1 ca passe plus... le 2.5 déja suivant le numero du patch, un coup ca passait, un coup non

Pis gueuler paske sur un noyau beta, avec un patch, y'a un driver pas concu pour a la base mais patché a son tour qui refuse de tourné, faudrait penser a etre un peu realiste  
 
déja que quand c tout fait pour ca merdoix de tmps en tmps  

Les drivers nvidia marchent tres bien avec le mm1
Le changement de console virtuelle aussi, t'as du oublier de compiler un truc
 
Pour le reste faites confiance à notre kernel guru à nous, Udok

 
 
si vous savez quoi, je suis preneur... parce que le driver nv est pas bien rapide  

et kesse j'aurais oublié de compiler !???

 
bon le flambeur, qu'est ce que j'ai oublié ?    

j'en sais rien, moi tu sais les gentoo ...  

un monsieur pas gentil detectaid !!!  
EDIT : pas de vulgarité, il a dit...  

 
pas de vulgarité !  

excuse j'édite lol

 
trop tard, quotaid !  

Comme vous avez du le voir, le 2.6.0-test2 est sorti hier, et le -mm1 est déjà disponible !

• Article LinuxToday (l'annonce de Linus)
• Les patches -mm pour le noyau 2.6.0-test2

Au menu : des nettoyages, du portage de drivers du 2.4 par Alan Cox, et l'intégration de quelques améliorations des séries -mm de Andrew Morton. La routine quoi . Tous les efforts se concentrent donc pour rendre ce noyau 2.6 utilisable.

Support for frame buffer devices (FB)
 
The frame buffer device provides an abstraction for the graphics
hardware. It represents the frame buffer of some video hardware and
allows application software to access the graphics hardware through
a well-defined interface, so the software doesn't need to know
anything about the low-level (hardware register) stuff.
 
Frame buffer devices work identically across the different
architectures supported by Linux and make the implementation of
application programs easier and more portable; at this point, an X
server exists which uses the frame buffer device exclusively.
On several non-X86 architectures, the frame buffer device is the
only way to use the graphics hardware.
 
The device is accessed through special device nodes, usually located
in the /dev directory, i.e. /dev/fb*.
 
You need an utility program called fbset to make full use of frame
buffer devices. Please read <file:Documentation/fb/framebuffer.txt>
and the Framebuffer-HOWTO at
<http://www.tahallah.demon.co.uk/programming/prog.html> for more
information.
 
Say Y here and to the driver for your graphics board below if you
are compiling a kernel for a non-x86 architecture.
 
If you are compiling for the x86 architecture, you can say Y if you
want to play with it, but it is not essential. Please note that
running graphical applications that directly touch the hardware
(e.g. an accelerated X server) and that are not frame buffer
device-aware may cause unexpected results. If unsure, say N.

 
ça rajoute des options au kernel ?  
nan parce que je viens juste de terminer la config, je m'appretais à compiler alors je veux bien patcher mais si il y a qq'chose à cocher, faudrait me le dire maintenant

j'ai ma réponse :
NSA SELinux Support (SECURITY_SELINUX)
 
où qu'on peut avoir la liste des options rajoutées ?

bon bah j'ai compilé sans reconf ... au moins la compil est propre par rapport aux kernel 2.4

presque trop même, ca fait moins geek    
Mais c'est plus lisible

 
bah oui, c'est ça qu'il faut retenir : on n'a pas besoin de voir 15000 fois les lignes "gcc -machinbidule ..."
là on voit ce qu'on a besoin de voir (et pas grand chose tellement c'est propre ), sans avoir à chercher dans un vaste fouilli inutile
bravo aux devels qui font vraiment un travail remarquable en tout point  

mon test2-mm1 marche ! du premier coup
comme quoi ça finit par rentrer, à force de faire des conneries
 
 
bon, il subsiste qq pb :
 
 

 
bizarre ça, c'est normal ou quoi ?    
 

 
céslameume    
 
plus embétant maintenant :

 
ça vaut bien les écrans bleux de windows    
 
 

 
c'est grave docteur ?
 
 

 
là je pense que c'est ma faute
 
bon voilà, j'attends vos impressions, surtout sur le truc à gueule de bsod  

 
ben je l'ai compilé sans mes optimisations habituelles tout à l'heure et je dois dire que je suis sur le cul quoi.... depuis quelques temps j'utilise des noyaux suse en 2.4.20 qui ont une meilleure réactivité que les 2.4 de base avec preempt et là le 2.6.0 test 2 supplente carrément les noyaux suse  
c'est là que je dis que je n'ai eu aucun soucis dessus à part un problème de conversion de nom de modules comme usb_ohci qui est devenu ohci-hcd, donc mon modprobe.conf n'est plus à jour, mais sinon ça tourne trop bien et je me suis bien marré au lancement de X + kde et sur ut2003 pour tester... dommage qu'il n'y ait pas le support 2.5/2.6 pour les drivers réseau nforce2 (nvnet) comme fait minion.de pour les drivers graphiques

 
'tain ! tout comme moi
moi aussi il a fallu que je tripatouille pour le ohci
et moi aussi j'ai un nforce2  
par contre mon nforce2 est sur ma machine principale donc c'est la merde, je peux pas tester X, j'ai pu testé que ma passerelle et c'est plutot difficile de voir les changements
j'ai quand même l'impression que la console est plus rapide
bah oui, une vieille passerelle toute moisie avec mldonkey qui bouffe toutes mes ressources, c'est idéal pour tester la réactivité de la ligne de commande  
 
mais j'aimerais bien pouvoir faire marcher mon nforce2
pour protester, viendez témoigner votre mécontentement ici :
http://www.nvnews.net/vbulletin/sh [...] adid=15548
 
si on pouvait ne pas attendre 6 mois pour qu'ils sortent le driver

 
j'ai dit une connerie, je viens de trouver j'ai patché les sources nvnet pour compiler sur mon 2.6.0-2  
 
allez valà l'adresse où tout est dit : http://www.nforcershq.com/forum/viewforum.php?f=29

yais !      
et pour nvaudio, ça compile bien ?

 
j'ai une 7NJS donc pas d'utilisation de l'APU nforce mais un C-Media 8738 à la place, que je n'utilise pas finalement, je préfère ma sblive platinum et là ça craint car les drivers emu10k1 0.20a ne passe pas sur les séries 2.5/2.6, c'est la seule chose qui a retardé mon passage au 2.5 quand j'avais mon ancienne carte mère
 
en fait j'utilise bcp le live drive, y compris la sortie casque et là manque de bol avec le module de base du noyau et alsa j'ai pas eu moyen de sortir qq chose
 
mais bon, le 2.6 servira qd j'aurais besoin de perf dans les LAN sans casque obligatoire par exemple

bon bah m'en vais tenter le coup alors, sait-on jamais...

ah ben me voilà sous le 2.6.0-2 avec le module nvnet  
 
 
et...... put1 !!! ma sortie casque fonctionne sous ce noyau !!!!!!!!!!!!!!!  
 
bon ben 2.6 addicted

 
 
ça commence bien !
 
c'est quoi ce bazarre ? le patch est déjà mis maintenant ?
dans le patch mm1 peut-être ?

 
et moi je vais me retrouver comme un con avec mon nvaudio  

 
ce sont les sources NVIDIA_kernel qu'il faut patcher, les sources des drivers nvidia quoi !!! pas celles du kernel hein

 
c'est compliqué  

ah ça y est, j'ai réussi
je cherchais une doc mais y-a plus vite fait de chercher soit même le répertoire à patcher  
bon, et après, ça s'installe comment les drivers nvidia ?
je suis un habituer du .deb moi

bon je résume :
 
- les drivers graphiques nvidia : tu chopes les sources sur le site de nvidia, tu extraits NVIDIA_kernel et NVIDIA_GLX, tu installes ce dernier en faisant un simple make, tu patches avec le fichier dispo sur minion.de "NVIDIA_kernel-1.0.4363-2.5.diff" les sources NVIDIA_kernel-1.0-4363
 
- pour nvaudio, tu chopes les drivers nforce 0261 sur le site de nvidia, tu extraits, tu choppes le patch nvaudio et nvnet à partir des lien proposés sur le forum que je t'ai dit plus haut, tu patchs dans les 2 répertoires "nvaudio" et "nvnet" obtenus après extration du tarball nforce 0261
 
c'est compliqué ça ?
 
sinon il existe aussi un patch pour lm_sensors 2.8.0 (à appliquer sur ce dernier) pour faire fonctionner les sondes correctement, dispo aussi à la même adresse sur le forum
 

 
make tout connement, mais faut d'abord booter sous le noyau 2.6, ça évitera de modifier un lien symbolique et d'avoir des soucis même

ok
donc pour le glx il est déjà installé, donc pas besoin de refaire j'imagine
c'est pour le kernel que c'est chiant, mais un make c'est pas compliqué en fait
 
pour les sensors c'est bien parce que quand j'avais essayé c'est pas ça

personnellement avec lm_sensors, j'ai une erreur sur les sources du bus nforce2 (pas de bol, c'est juste le bus qu'il me fallait), j'ai pas cherché à forcer, de toutes façons depuis que j'ai la 7NJS j'ai plus de mesures software, avec une senfu j'ai toujours le même résultat au moins

enfin tout ça c'est bien minion mais s'il faut faire tout ce bordel à chaque test et chaque pre, on est pas rendu

piting' ! y-a même à patch pour l'acpi ... on en sortira donc jamais  

 
tu fais un script  
 
c'est ce que j'ai fait pour les 2.4, c'est partout pareil, pour les 2.5/2.6 c'est devenu pareil maintenant, tu gardes tes tarball de sources nvidia et autres dans un coin fixe et tu fous les commandes dans des blocs conditionnels pour gérer les erreurs et les mises à jour éventuelles des tarball, et voilà  
 
tu lances ton script, ça extrait, patche, copie ton ancienne config kernel là où il faut, lance menuconfig par exemple, tu modifies si besoin, tu enregistres et la compilation part toute seule, installe les modules, le kernel, modifie lilo/grub, reboot.... tu gagnes un temps fou avec ça

 
PAS D'ACPI NI D'APIC SUR NFORCE2 !  
 
tu vas souffrir sinon, vive les erreurs, si t'as jamais vu des démons et des modules planter, tu actives les 2 : le spectacle sera meilleur
 
sérieusement, ne mets que l'apm et vire IO APIC et ACPI, parce que c'est pas encore très stable l'acpi sur nforce2, testé et approuvé

 
pas betes, je me ferais peut-être ça tient