Noyau 2.6.16 bugué ?

Support Debian
#1

Bonjours tous le monde,

j’ai installé debian amd64 avec le noyau 2.6.12,

j’ai voulu installer le noyau 2.6.16.1
au lancement de make menuconfig le noyau regarde la configuration du noyau 2.6.12 et essaye de mettre les meme options, sauf que je me suis appercu que beaucoup d’option ne sont plus pris en compte par le noyau 2.6.16.1…

normalement si on compile direct le nouveau noyau avec les option du noyau de base tout devrais marcher hors quand je boot sur mon nouveau noyau 2.6.16.1 tout neuf et bas j’ai plus d’affichage ?

le noyau 2.6.16 ne se lance pas à moin de ne pas mettre “vga=” dans lilo ou grub, cool super noyau en 640*480… et le seul moyen que j’ai trouvé pour résoudre se probleme c’est de compiler en dur l’option :
Device Driver>Graphique support>Console display drivers support>Framebuffer Console support,
ce qui fais ramer exessivement la console…

alors noyau bugué ou pas ?

#2

bonsoir,
c’est peu probable vu que c’est un noyau stable …
je pense qu’un dpkg-reconfigure xserver-tonserveur devrait remédier à ça … en choisissant les bonnes options concernant l’écran …

#3

salut,

merci pour ta réponse mais :

je ne connaisais pas xserver, ne l’ayant pas sur mon pc, j’ai cherché a quoi cela correspondais et je me suis rendu compte que cela sert a XFREE ou a Xorg
hors je n’est pas installer xfree86 ni Xorg…

et mon probleme est uniquement au sujet du boot des noyaux 2.6.12 et 2.6.16, genre pour que le boot marche avec “vga=” faut installé xfree ??

je cherche la configuration de l’ecran ou de la carte video niveau console et de toute facon sa n’arange pas le probleme de boot entre les deux noyaux.
(up)

carte ATI RADEON 9250
proc AMD 64bit
carte mere k8-comboZ

merci quand meme…

#4

[quote=“fabien493”]
le noyau 2.6.16 ne se lance pas …[/quote]
Je pourrais pas t’aider, mais dis quand même le message qui s’affiche au boot, sur lequel ça bloque, ça pourra être util …
@+

#5

Salut, pour ceux qui n’on pas compris, j’avou je m’éxplique mal…

quand je lance le noyau du cd d’install 2.6.12 avec dans grub “vga=791” tous marche nickel .
quand je lance le noyau 2.6.16 avec dans grub “vga=791” plus d’affichage au boot

donc je ne peut savoir ce qui ne vas pas .

la seul possibiliter d’avoir l’affichage avec dans grub “vga=791” est de compiler le modules :
Device Driver>Graphique support>Console display drivers support>Framebuffer Console support,
EN DUR, ce qui fais ramer exessivement l’affichage !

je rapelle que les deux noyaux ont la même config,

merci, je pense que c’est un probleme du noyau, que les programeur n’ont pas pensé ce qui fais que je doute arriver un jours à trouver d’ou ça viend.

personnes à une adresse mail ou envoyer les bogs des noyaux?

si quelqu’un veut téster:
telecharger le noyau 2.6.16,
(mettre : Device Driver>Graphique support>Console display drivers support>Framebuffer Console support, DESACTIVE ou en MODULE)
compiler,installer,
mettre vga=791 dans grub ou lilo et reboot
lancé noyau 2.6.16 si sa marche je paye des cerises.

#6

supprime de ton grub
"vga=791"
moi j’en ai pas et je m’en passe très bien.

#7

merci pour ta réponsse honnette,

sache que je passe la plupart de mon temp en mode console,
(programmation, et developpement)
que je ne peut me permettre d’avoir une console qui rame, et ou une console ou les caracters sont trop gros.( ou je vais mettre 3 plombe à afficher une page alors que normalement il me faut 1s)

si je ne trouve pas de solution à ce probleme un rapport de bog sera envoyer…

en attendant je vais utiliser ta solution, en ésperant qu’un jours ce probleme trouvera une solution…

Mais je crois pas au faite que tout les utilisateurs de debian ne mette pas “vga=” dans lilo ou grub ou alors compile le module Framebuffer Console support, en dur

vraiment je ni crois pas !

merci quand même…

#8

non je ne pense pas qu’il sagisse d’un bug, mais d’une option que vous avez du oublier, ou mettre en trop.

Je ne peux pas aider comme ça, faudrais que je vous le menuconfig et la conf de la machine …

Paste ton .config, un lspci un cat /proc/cpuinfo
j’essayerais de regarder…

#9

Attention, il y a eu une grosse évolution entre le 2.6.12 (ou 13) et le 2.6.14 et suite, le système devfs a disparu entre autres. Regarde dans le Changelog les évolutions du noyau sur le framebuffer.

Il n’y a pas de branches 2.7 dans le noyau ce qui fait que les développements sont appliqués sur le noyau en cours. On ne peut considérer que le 2.6.16 est un noyau stable.

#10

Fabien, je comprends que tu sois préoccupé par ce problème de compilation, mais fais tout de même gaffe à l’orthographe. Ca finit par ressembler à du langage SMS.

#11

AMA, qu’il soit en dur dans le noyau ou en module, le même code provoquant les mêmes effets ça ne devrait pas changer la vitesse d’affichage.
Par contre, une fois activé le support du FB dans le noyau (qui ne doit sans doutes pas se charger correctement dans ton cas quand il est en module), il y a aussi le choisx du module de framebuffer: si ça se trouve, ton systême charge un framebuffer genre vgafb (trés générique), alors qu’il existe peut être un framebuffer plus specifique (atifb ? radeonfb ? je n’ai que des nvidia). Il faudrait peut être forcer le bon pilote fb ?
Sinon, autre questions:
ce 2.6.16, les sources viennent d’un depot debian ?
et au cas ou tu l’aurait telechargé depuis kernel.org (première cause possible d’instabilité), l’as tu compilé avec make-kpkg ?

#12

PS: moi aussi je bosse toute la journée en console, mais je suis en konsole sous X, ça me fait beaucoup plus de consoles, et je peux en plus les surveiller pour les activer automatiquement si la sortie d’un tail -qf s’agite, etc…
Avec le matos que tu as, c’est un peu masochiste de rester en console, à moins que tu ne développes spécifiquement pour la console, ou que tu ne sois sur un serveur (mais j’imagine que tu ne développes pas sur un serveur).
Mais bon, les coups et les douleurs de Geeks… :wink:

#13

Bonjours tous le monde,

(Je vais faire un effort sur l’orthographe)

Bon, voila ayant poster ce problème sur la plupart des forums LINUX, j’ai eu pas mal de réponses, entre autre le faite que ce bogue, est arriver à d’autre personnes que moi,

Pour ed :

J’ai testé plusieurs configurations de ce noyau, sans arriver à trouver de solution,
Sauf compiler l’option : « Framebuffer Console support » en DUR
Et ce problème est arrivé à plusieurs personnes qui on voulu installé ce noyau, avec un pc différent, une carte graphique différente, et un proc différent, donc ce n’est pas un problème de configuration de la machine mais un problème de configuration du noyau que les développeur non pas pensé.
Ps : le noyau 2.6.12 na pas l’option : « Framebuffer Console support » en dur mais en module avec dans grub « vga= » et marche impeccable, en lançant vesafb au boots… (Pas de latence de la console)

Pour MattOTop :

Sache que le noyau 2.6.12 lance au démarrage vesafb et vas super vite pas de l’attence, même en 1280.1024
En effet il existe d’autre framebuffer spécifique à ma carte, mais si je décide de le compiler je ne pourrais plus utiliser les dernier driver de chez ati sous X (cause de problème de compatibilité) > andesi.org/index.php?node=99#A4

Les sources viennent de kernel.org ainsi que toute les sources des noyaux que je télécharge.
Et non je le compile à ma façon : make clean> make >make modules_install >make install, et cela à toujours parfaitement fonctionner.

Pour info : une seul personne qui à pu trouver une solution à ce problème (qui n’est toujours pas officiel, mais sa solution n’est pas au niveau noyau donc, noyau bogué !)

Solution mettre dans grub : « video=vesafb:ywrap,mtrr,1280x1024-24@85 » à la place de « vga= »
Solution non tester sous lilo .

Merci

#14

Mwahahahaha.

Hey, faudrais peut être comprendre ce qu’il se passe, et arreter de prendre les gens pour des cons, avant de vouloir donner des leçons.

Bonne chance.

Topic vérouillé