Reprise du message précédent :
Bonjour,
ou je pourrais trouver l'ensemble des instructions que l'on peut utliser pour creer un module pour le kernel.  
Merci de votre aide.

http://www.tldp.org/LDP/khg/HyperNews/get/khg.html

 
 
à noter pour l'occasion la (tentative de) sortie d'une nouvelle branche stable :
http://lkml.org/lkml/2005/12/3/55
qui n'a pas que du soutiens on dirait

projet de développement de pilote libre pour les cartes nvidia :
http://linuxfr.org/2006/03/20/20525.html

Le pourquoi du comment.
C'est clair que comme ça on dégage pas mal de problèmes.
Et ma télécommande ? et ma CG ?
 
Bref, ça peut être utile pour les serveurs mais pour les desktops c'est moins évident.
 
Dis-donc toi le barbu tu vis dans une caverne maintenant ?

perso j'ai toujours pas compris comment fonctionne les nouvelles options pour gérer la mémoire ...
moi j'ai 1Go, c'est bien comme ça :

 
mon dieu non, quel horreur, pas d'électricité, pas de pc, pas de net  

 
L'api/abi pour le userspace est très stable (sauf quelques morceaux de sysfs qui viennent d'être ajouté)
 
c'est l'api/abi pour les modules hors kernel, typiquement les modules propriétaires, qui n'est pas stable pour éviter de limiter le potential de développement. en clair on n'hésite pas à casser les interfaces internes lorsqu'on en a besoin. Ce qui serait impossible si on maintenait des trucs stables.

apparemment, problème avec les nvidia qui ne compile pas avec ce nouveau kernel.
La solution est ici :
http://www.nvnews.net/vbulletin/showthread.php?t=62021

Ça compile avec les paquets Gentoo .
 
Sinon, Alsa 1.0.10 ne passe pas là (mais le cvs du jour oui, mais le son reste en deça quand même).

 
Sinon quelle est la version d'Alsa dans le 2.6.16 (car j'ai pris l'option externe comme d'hab) ?

1.0.11rc2

Arf, pas terrible (j'aurais espéré une version stable ).
 
Merci.

 
c'est pas la 1ère fois.

hmmm... je rêve sans doute mais j'ai l'impression que le nouveau kernel m'a viré les modules netfilter  
apparemment y-a une nouvelle option nommée CONFIG_NETFILTER_XTABLES
par défaut elle est pas activée
sauf que This is required if you intend to use any of ip_tables, ip6_tables or arp_tables.
super ça  
 
bon, ça plus les nouvelles options de la mémoire qui ne sont pas documentée plus le risque de casser encore une fois les drivers nvidia ... je vais attendre un peu avant de le mettre moi  

udok : oui, netfilter a changé de place, enfin, en partie (make oldconfig et ensuite, tu peux ajuster précisément).
 
mirtouf : c'est le cvs de ce jour chez moi aussi (car le paquet 1.0.11-rc3, c'est même pas la peine niveau qualité du son ...). Bon, en fait, ça va à peu près , après quelques tests.  
Ah, ok, je n'avais pas saisi que tu voulais parler du 2.6.15 et de la version Alsa, par défaut.

Les options de la mémoire ne sont effectivement pas documenté (ou alors je n'ai pas trouvé) ce qui est domage du fait que le règlage est important dans la mesure où il influe sur le type d'utilisation qu'on fait de son système ; il est question de choisir un mode de répartition pour la mémoire disponible entre l'espace noyau (le système) et l'espace utilisateur (les applications) mais plus d'infos à ce sujet seraient les bienvenues.
 
Les options iptables ont effectivement changé, j'avoue avoir un peu cherché pour comprendre leur nouvelle organisation et choisir les bonnes options mais ça va, rien d'incompréhensible de ce côté-là ; si j'ai bien compris leur nouvelle logique, il s'agit de réunir ensemble (netfilter core) les options communes à ip_tables, ip6_tables et arp_tables (d'où le 'x'_tables), les options spécifiques restant à part. A terme je crois que cette organisation sera plus claire et on pourra plus facilement si retrouver, ce qui n'est pas mal en fin de compte.
 
Toujours du point de vue organisation, globalement ellen'a pas beaucoup changé, mais on peut quand même constater que quelques efforts ont été fait pour mieux structurer les menus/sous-menus et options ; un bon point également.
 
 
 
Passons maintenant aux inconvénients que j'ai constaté:
 
 
- les drivers nvidia ne fonctionnent plus en l'état (il faut les patcher) ; cela étant le patchage est très simple à réaliser, et les drivers fonctionnent correctement chez moi jusqu'ici (au bout de deux jour d'utilisation).
 
 
- j'ai remarqué une importante baisse de réactivité après quelques heures d'utilisation sous Gimp : à l'ouverture de nouveaux fichiers d'un coup le simple affichage d'un menu met de très longues secondes, et le fait de switcher entre un autre bureau et celui où Gimp est ouvert provoque un temps de rendu de fenêtre très long avec une utilisation du processeur qui frôle les 100%, puis au bout d'un moment tout revient à la normale...    
 
On dirait que c'est comme si les données avait été mises en swap et relues à partir de celui-ci (alors que le swap n'est pourtant pas utilisé puisqu'il m'indique 0k au moment du problème) ; c'est bizarre d'autant que pendant ce temps les autres apllications ne sont pas affectées et qu'en temps normal le noyau est particulièrement réactif (j'ai remarqué une nette amélioration à ce niveau entre le 2.6.15 et le 2.6.16).
 
Bref cela reste à élucider : est-ce que c'est lié à cette fameuse nouvelle option pour la mémoire ? est-ce qu'il s'agit d'un bug dans Gimp ? d'un problème créé par les drivers nvidia patché ? Faudrait que je pousse les investigations pour cerner d'où ça peut venir, toujours est-il que c'est la première fois que je rencontre ce genre de problème    

Pour les options memoire, la reponse est ici: http://kerneltrap.org/node/6067
 

Le suspend-to-disk marche chez vous ?  
Passque chez moi, pas moyen, alors que c'est sans souci avec le 2.6.15.6

THRAK > tu nous tiens au courant ?  

 
merci à toi mais ça c'est juste une explication (déjà lu pour ma part) du pourquoi de l'option, pas une documentation
 
enfin à priori pour une machine avec 1Go, il faut mettre DEFAULT_1G, mais j'espere qu'ils règleront vite ce problème de doc

pas très clair en effet.

Si vous avez utilise le dos pour jouer (a l'epoque de MS-DOS 5.0 -> 6.2), vous avez sans doute remarque une limitation du systeme: il ne peut addresser directement que 640 Ko de ram, le reste doit etre mappe (passer par une sorte de table qui traduit les addresses). La pagination etait geree par emm386 et autres, divisant la ram en une partie basse/haute et une partie paginee (mappee). Evidemment, pour tirer parti de la memoire paginee, les programmes doivent etre ecris pour.  
On retrouve ici un probleme similaire; l'option depend entierement de ce que vous faites tourner en userspace.
 
Cette option ne concerne donc que les cpu < 64 bits qui ont plus de 860Mo de ram. L'option permet de choisir comment la memoire va etre divisee. Voici un man (reducteur) des options disponibles:
 
3G/1G: Choix par defaut. Fonctionne a priori pour tout le monde. Si on a plus de 860 Mo, le "reste" sera disponible en tant que memoire mappee.
3G/1G (Full 1G): Permet a ceux qui disposent de 1Go de ram de tout addresser en memoire basse.
2G/2G: Idem pour ceux qui ont entre 1Go eet 2Go de ram
1G/3G: Mais a quoi ca sert
 
La (actuellement) future page de man:
 
+   Select the desired split between kernel and user memory.
+
+   If the address range available to the kernel is less than the
+   physical memory installed, the remaining memory will be available
+   as "high memory". Accessing high memory is a little more costly
+   than low memory, as it needs to be mapped into the kernel first.
+   Note that increasing the kernel address space limits the range
+   available to user programs, making the address space there
+   tighter.  Selecting anything other than the default 3G/1G split
+   will also likely make your kernel incompatible with binary-only
+   kernel modules.
+
+   If you are not absolutely sure what you are doing, leave this
+   option alone!

Concretement parlant, je mets quoi comme option avec 1GO de ram ?
pour l'instant j'ai 860Mo de ram de detecter

Processor type and features  ---> Memory split > 3G/1G user/kernel split (for full 1G low memory)  

ok merci
 
enfin j'arrive pas a compiler le driver nvidia avec le 2.6.16

faut patcher.

avec quoi ?

http://www.nvnews.net/vbulletin/at [...] 1137942929
 
http://www.sourcemage.org/node/1546

merci, ca marche bien.
 
Quelqu'un sait quand les drivers pour les cartes wifi RT2500 (ralink) seront nativement dans le noyau ?
 
c'est pénible a chaque nouvelle version de recompiler tout ca

Je vais voir ça cette semaine si j'ai le temps    ; le truc chiant c'est la procédure longue à utiliser pour tenter de déceler d'où vient le prob, car il faut utiliser Gimp pendant un certain temps avant que ça se produise. J'ai déjà jeter un oeil au niveau des logs mais il n'y a rien d'anormal, c'est donc un truc plus subtil.
 
Le plus simple je crois, est peut-être de commencer en utilisant le 2.6.16 avec le driver 'nv' et lancer Gimp en ligne de commande avec l'option --debug-handlers et voir ce que ça donne.
 
 
Sinon la config mémoire est quelque peu épineuse, d'après ce que j'ai pu lire sur kerneltrap et pour reprendre ce que Canth a indiqué précédemment, la problématique se situe sur l'accès du noyau entre mémoire basse et mémoire haute sur les systèmes 32 bits.
 
Sur un système avec moins d'1 Go de RAM le problème est vite règlé puisque la taille d'allocation par défaut  est suffisante et permet au noyau d'accèder directement à l'intégralité de la RAM. En revanche sur des systèmes ayant 1 Go de RAM ou plus, se pose le problème d'une taille d'allocation maximale de 896 Mo -la mémoire basse- (limitation de l'architecture 32 bits, avec le 64 bits le problème ne se pose pas) ; pour contourner cette limitation, intervient donc le concept de mémoire haute qui permet au noyau d'accéder au surplus de mémoire disponible.  
 
Le hic c'est que la mémoire haute nécéssite d'être mappée au préalable dans le noyau pour pouvoir y accéder, ce qui peut entraîner une baisse de performance en particulier sur les systèmes avec beaucoup de RAM (ainsi avec 4 Go de RAM, 3128 Mo sont placés en mémoire haute, ce qui commence à jouer si cette portion nécessite d'être fréquemment accédée par le noyau).
 
Arrive donc cette fameuse nouvelle option qui permet d'accroître la quantité de RAM accessible en mémoire en jouant sur la taille adressable entre espace noyau et espace utilisateur (on alloue alors plus au système au détriment des applications); comme précisé, le revers est que des incompatibilités peuvent se produire au niveau des binaires externes au noyau (plus particulièrement les modules proprio à la nividia ou ati, encore que sur kerneltrap un dev indiquait faire fonctionner des drivers nividia 8178 avec un des autres schémas d'allocation que celui par défaut), que cela peut entraîner des problèmes de fragmentation mémoire supplémentaires en fonction de la quantité de mémoire et du schéma de "découpage" employé et bien évidemment que cela s'adresse plutôt aux systèmes ayant d'avantage besoin d'espace noyau que d'espace utilisateur (donc limité à certains serveurs ou clusters).

on peut compiler gimp avec le support gdb ?

quand les développeurs se seront entendu sur une implémentation du protocole 802.11 et que quelqu'un l'aura programmé

Lancer le tout avec la commande gbd gimp ne fonctionne pas    
 
Sinon aucune idée à ce niveau.

Pourquoi on ne pourrait pas

aujourd'hui, sortie du 2.6.16.1, du 2.6.16-mm2 et surtout du 2.6.15.7...

 
Bcp de problemes avec le driver ATA Intex PIIXn sur mon portable (IBM T23), pas moyen de booter  
 
2.6.16 en attendant le 2.6.16.2    
 
Ca devient recurrent depuis la suppression du tree 2.5, vivement le 2.6.7

2.6.17

Quelqu'un a deja eu des blems ? Sur ma NF7-S (nforce2) j'ai le module PS/2 qui oops en 2.6.14/2.6.15/2.6.16

psmouse ?
aucun problème pour moi.

 
Je voulais dire 2.7.x, histoire qu'on ait pas l'impression de compiler un snapshot de 2.5.x quand on compile un 2.6.x
 

Juste une précision, oups, ca te fait planter toute la machine ou c'est juste un message dans les logs? J'ai un problème de plantage de Debian qui vient de je ne sais où, peut etre le meme probleme vu que j'ai une souris en PS/2 sur une NF7-S (kernel 2.6.15-1-k7)