Reprise du message précédent :

 
http://www.nvnews.net/vbulletin/sh [...] p?t=110088
2.6.25 vanilla + NVIDIA-Linux-x86_64-169.12-pkg2.run

Pour trouver les modules qui prennent du temps à compiler et qui servent à rien .
 

Personne n'a de souci avec alsa et le 2.6.25 ?
 
Précison, ma question concerne ceux qui utilisent les paquets de leur distribution ou qui compilent à la main (bref, ça ne concerne pas ceux qui utilisent les pilotes intégrés dans le noyau).
 
edit : je viens de prendre ceux intégrés et plus de souci (étrange cependant, car même avec la version dev, il y a des soucis, des modules sont zappés).

D'après la log de git, j'ai l'impression que ce qu'il y a dans le noyau ne correspond pas exactement à une 1.0.16rc2 ou 1.0.16, mais à un truc entre les 2, donc des différences peuvent se comprendre.

ca marche chez vous le 2.6.25-1 de debian sid avec lNVIDIA-Linux-x86-173.08-pkg1.run ?
 
il est dit:  
The 173.08 NVIDIA Linux graphics driver release does not require patching.
 
mais ca plante a l'installe chez moi

Si c'est l'install de nvidia qui plante, ce serait plus logique de poster sur le topic nvidia, sinon, faut être plus clair.

bonjour,

j'ai installé opensuse 11 RC1 sur mon pc équipé d'une carte wifi Dlink DWA-547 chipset atheros AR5416, théoriquement supporté par ath5k qui doit être présent dans le 2.6.25

une fois l'installation finie, je me précipite dans la configuration pour voir si je peux avoir le wifi directement.

malheureusement, ça n'est pas le cas.
dans la zone hardware, la carte est bien présente.
dans la zone "network interface", la carte est présente également, mais aucun nom d'interface ne lui est associée (eth0 est attribué à ma carte ethernet, mais rien n'est défini pour la carte wifi).

faut il faire quelquechose de spécial dans le noyau ?
je vais poster également dans le topic opensuse

merci d'avance.

J'ai une carte atheros avec un support bancale, c'est a dire qu'elle est detectee, mais inutilisable.
Verifie si le support est bon pour la tienne.
Tu peux aussi regarder du cote de compat-wireless qui sera plus recent que le kernel je pense.

merci pour ta réponse.
j'ai oublié de préciser que je suis un peu noob.
 
où vérifier que "le support est bon" ?
compat wireless ? visiblement après une petite recherche, c'est un projet de drivers de carte wifi pour patcher des noyaux ?
ath5k est inclu dedans ? ou alors c'est autre chose ?
et pourquoi ça marcherait si avec ath5k ça ne marche pas ?

Sur la page d'ath5k http://madwifi.org/wiki/About/OpenHAL
 
Sinon wireless-compat te donnera une version plus recente d'ath5k que celle disponible avec ton noyau.

bon, mon AR5416 n'a pas l'air de faire partie des cartes supportées
wireless-compat ? je le trouve dans les logiciels dispo alors ?
 
bon, je rebranche mon cable ethernet, je reboot sous opensuse 11 RC1 et je verrais.

bon, c'est la galère sous opensuse, je n'ai pas trouvé comment installer wireless-compat.
 
on va dire que j'abandonne pour l'instant.
d'autant qu'opensuse ne m'est pas familié, et que je trouve le menu d'administration on ne peut trop complet.

Wireless tu le telecharges depuis la page du projet avec les instructions pour l'installer.

ok, ben quand j'aurai un peu de temps alors
 
merci.

Le 2.6.26 final vient de sortir.

et moi je compile le 25 hier

Ton avatar n'a plus qu'a appuyer sur la gachette  

C'est ce que je pensais, mais j'ai pas osé T.T

Pour une fois pas de régression sur x86_64. Bravo les gars
 
Par contre, dans hid, c'est toujours pas réglé pour les claviers apple

 
Quel problème exactement ?

Le pb_fnmode. L'option qui par défaut privilégie les utilisateurs d'Aqua sous Linux par rapport aux utilisateurs de KDE ou Gnome ...
Et aussi les touches ²³ et <> qui sont inversées.
Puis ce serait cool qu'une pression "à vide" de la touche fn donne un code pour récupérer la touche insert.

 
Pour les touches inversée, xmodmap peut corriger ce problème. Pour le second problème, en passant par evdev, la touche fn ne sort aucun code ?

 
Tiens j'ai posté aujourd'hui sur ce "problème" justement    
http://forum.hardware.fr/hfr/OSAlt [...] m#t1060654
(j'ai un Apple Keyboard Alu)
 
It's not a bug, it's a feature    
 
Sinon aucun problème de touche, qwerty inside

Sauf que tout le monde n'utilise pas X
 

Faut que ça change

[quotemsg=1061106,6223,7832]
Sauf que tout le monde n'utilise pas X
 
 
 
Si c'est pour la console, t'as essayé les différentes keymaps pour claviers mac avec loadkeys ? Le package qui les contient s'appelle console-data sous debian. Il y en a peut-être une avec les touches dans le bon ordre

Essaye de faire Ctrl-Alt-fn-F2 juste pour voir

3615 mylife
Trop cool mes patchs ont été intégrés dans la 2.6.27-rc1

Tiens, le 2.6.26 n'a pas eu de nouvelle release en 2 semaines (contre 2 pour le 2.6.25).

bon le 2.6.27-rc2 est sorti.
 
sinon, je viens de voir ça sur le changelog du 2.6.27, quelqu'un pour m'expliquer l'intérêt ?

L'async utilise des buffers internes de lecture/écriture, ce qui évite d'avoir à mapper certaines pages en mémoire (ou se retrouver dans des mécanismes couteux genre page-fault/page-in) si la page n'est pas présente. Les flush sont moins couteux aussi, vu qu'ils sont traités en batch.

je suis pas sur d'avoir tout compris mais au moins c'est un peu plus clair

C'est exactement le même principe que l'on retrouve partout quand on veut éviter des overheads importants: on groupe les opérations. Mais ca oblige à les loguer dans un buffer (faut bien les mettre quelque part ), pour les commiter plus tard (au moment optimal). Ce qui complexifie l'opération (il faut quand même garder l'état du filesystem cohérent, d'un process à l'autre).
 
C'est critique ici, car pour linux, la glibc utilise un montage tmpfs pour les sémaphores nommées (l'ancien shmfs). Et vu que ca sert à synchroniser des programmes entre eux, ca peut faire mal
 
Exemple de buffer typique: fonctions de la stdio (les FILE *), posix_aio, writev/readv (les ancetres de posix_aio).

un bug sympathique avec les noyau 2.6.27rc :
http://blog.mandriva.com/2008/09/2 [...] -releases/
 
en substance, ça peut flinguer une carte réseau utilisant le pilote e1000e

 
C'est moins méchant qu'il n'y parait. D'une part, ça n'attaque que la fonction network boot et d'autre part, c'est facilement réversible en reflashant l'eeprom via software.

Pour que ça soit utile, il faudrait avoir un tmpfs à moitié swappé non ? j'imagine que c'est surtout là pour la complétude truc (comme les acl)

 
Effectivement, pour un fs purement mémoire, c'est là que ca va devenir sensible.
 
Et je dirais oui pour la deuxième remarque, normalement, tout le système de gestion de la VM de nunux devrait faire en sorte que les opérations se fassent proprement au niveau architecture. L'AIO n'apporte quasiment rien pour tmpfs, vu qu'on reste en mémoire, et que l'on ne nécessite pas d'augmenter artificiellement le débit en usant de buffers pour écrire vers un périphérique beaucoup plus lent.
 
Sauf exception avec le swap, mais là... se pose la question du bon tuning des partoches tmpfs. Blocs de 512 pour un disque, 4k pour les pages, il peut y avoir des surprises. Si on swap, c'est défavorable, de toute manière

Tiens canonical va être content pour sa prochaine release (dans 20 jours): le noyau 2.6.27 vient de sortir en version stable.  
 
Qui compile ce week-end?
 
http://www.kernel.org/

\_

Dire que j'ai compilé le 2.6.26.6 hier -_-"

Vous voulez dire que vous n'avez pas utilisé les 2.6.27-rc ??? Moi je tourne dessus depuis la rc1

trop peur de flinger ma intel e1000