[mise à jour] hors de portée au démarrage (résolu !)

[mimile]

J'ai appliqué ta rectification, exécuté mkinitcpio -p linux et rebooté.

Résultat : écran noir et le message "hors de portée"...

J'ai remis modprobe.conf dans son état initial options nouveau nomodeset et là encore écran noir et "hors de portée".

Lors de mes précédents essais (où je voyais défiler les lignes du boot, j'avais accéé à une console TTY et tenté un startx qui affichait une série de lignes et invitait à consulter var.log.Xorg.0.log

En voici le contenu : http://pastebin.archlinux.fr/456270

C'est à désespérer ... d'autant qu'avec le noyau 3.6.11-1 et le lts, je n'ai aucun souci.

EDIT : Dans son message du 22 janvier, Benjarobin évoquait un problème concernant KMS. Or, dans le pastebin, il est indiqué KMS not enabled. Y-aurait-il une piste à creuser de ce côté ?

[tuxce]

Il est "not enabled" parce que le module ne se chargeait pas suite à l'entrée erronée que je t'ai donné en premier.
Par contre, en ce qui concerne le message de benjarobin, quand tu as rajouté le nomodeset, vu que t'avais rajouté en plus un fichier de configuration (il faut toujours indiquer ce qui n'est pas par défaut) qui obligeait le KMS, ça n'a servi à rien.
(ceci dit, si ça fonctionne sans KMS, ça donnera juste une indication, ça ne résoudra pas ton problème car X refusera de démarrer)

Poste le journal d'un démarrage qui foire, ça peut éventuellement aider.

[mimile]

J'ai modifié le contenu de modprobe.conf en indiquant

Code : Tout sélectionner

options nouveau nomodeset

Ce qui permet à nouveau de voir défiler les lignes du boot.

Toutefois d'emblée, j'ai le message "unknown parameter nomodeset" et le boot se bloque sur la ligne reaching graphical interface

Je peux accéder à une console TTY.

Voudrais-tu me dire quel log t'intéresserait ?

J'ai examiné boot, Xorg.0, errors, everything, etc... sans y découvrir de lignes en relation avec "nouveau" ou "nomodeset".

A noter que quand je fais lsmod, nouveau n'apparaît nulle part alors qu'habituellement, il était mentionné face à un grand nombre de modules.

[tuxce]

nomodeset n'est pas une option du pilote, c'est le noyau qui la prend (enfin de ce que j'en sais, c'est plus à benjarobin cette option )
Pour le log, c'est le log du boot au redémarrage d'un boot qui se finit en écran noir et le message "hors de portée". Pour ça, tu notes l'heure, tu redémarres sur le noyau normal, sans option supplémentaire, ça devrait se finir avec l'écran noir, puis tu redémarrer sur lts et tu postes la sortie de :

Code : Tout sélectionner

journalctl --since "heure que t'avais noté"
# par exemple :
journalctl --since "15:00"

[mimile]

J'ai tellement fait de tentatives que je ne sais plus trop quand ça a planté avec un écran noir.

Ce dont je suis certain, c'est que depuis midi, cela s'est produit au moins deux fois.

Pour l'instant, je vois défiler les lignes de boot avec nomodeset (le dernier reboot) mais je crois que le précédent était un écran noir.

Je t'envoie le résultat des différents boot depuis midi.

http://pastebin.archlinux.fr/456292

Personnellement, je n'y vois pas de grandes différences.

Je vais tenter de reproduire les erreurs.

[tuxce]

il a pas l'air très cohérent le log ... des reboot avec direct une ligne sur gnome ... c'est bizarre

[mimile]

Pas très rassurant venant de ta part ...

En ce qui concerne nomodeset, c'est un paramètre qui n'est pas reconnu.

En revanche, on peut le remplacer par modeset=0 dans modprobe.conf ou alors dans grub.cfg (nouveau.modeset=0) à ajouter avant vga=791 dans la ligne linux ...

Ca aurait pour effet de désactiver KMS (si j'ai bien compris ...)

En attendant, je me contenterai de lts ou de downgrader vers 3.6.11-1

Je pense que l'origine du problème est que mon PC est décidément trop vieux (quoique nouveau soit censé géré ma carte).

[mimile]

Je reviens pour dire qu'enfin, mon problème a trouvé sa solution qui m'a été fournie sur un autre forum (http://forum.pcastuces.com/sujet.asp?pa ... ID=4703455)

Je peux enfin tourner avec le noyau 3.7.6.1

Pour voir, je conserve le LTS qui tourne sur le fallback.

Sujet résolu donc.

Je remercie chaleureusement tous ceux qui ont pris la peine d'essayer de me venir en aide même si les solutions proposées n'ont malheureusement pas eu le résultat escompté.

Cordialement,

[FoolEcho]

Juste pour dire que ce n'est pas vraiment (pas du tout même) solutionné puisque tu passes du pilote nouveau à vesa (pilote générique).
Par conséquent:

[tuxce]

Il passe à nv en fait.

[mimile]

Effectivement, on peut épiloguer sur les notions de "contournement" et de "résolu".

En ce qui me concerne, je persiste à penser que le problème est résolu dans la mesure où toutes les recherches que j'ai faites et les suggestions qui m'ont été données auparavant en relation avec "nouveau" ont échoué se terminant soit par un écran noir, soit se bloquant à la fin du boot.

Le fait est que la solution qui m'a été donnée par Logicien résoud la question et me permet d'utiliser les derniers noyaux (3.7.7 à ce jour).

Auaparavant, j'avais moi-même "contourné" le problème en downgradant le noyau 3.7 vers le précédent (3.6.11) et en installation le noyau LTS sur le fallback mais ça ne me satisfaisait pas.

Cela dit, je reste quand même perplexe :

1) Pourquoi les noyaux de la série 3.7.nnn rencontrent-ils (chez moi) un problème avec "nouveau", problème que je n'avais jamais rencontré jusque là ?

2) quand j'exécutais glxgears avec le noyau 3.6.11, les roues dentées (quand elles apparaissaient - ce qui était rarement le cas) tournaient par à-coups (un cran par seconde) mais la plupart du temps, j'avais uniquement un message m'indiquant une insuffisance de ressources avec retour direct au prompt.

Maintenant quand j'exécute glxgears (avec le pilote nv), les roues dentées tournent plutôt rapidement et avec régularité et m'affichent des valeurs de l'ordre de 18.000 FPS

Cela dit, c'est assez secondaire et le principal est que je puisse poursuivre mes mises à jour sans brider les mises à jour des noyaux.

[FoolEcho]

Effectivement, on peut épiloguer sur les notions de "contournement" et de "résolu".

... qu'est-ce qui m'a pris de remonter ce sujet...

Vite fait, à titre informatif:

Cela dit, je reste quand même perplexe :

1) Pourquoi les noyaux de la série 3.7.nnn rencontrent-ils (chez moi) un problème avec "nouveau", problème que je n'avais jamais rencontré jusque là ?

2) quand j'exécutais glxgears avec le noyau 3.6.11, les roues dentées (quand elles apparaissaient - ce qui était rarement le cas) tournaient par à-coups (un cran par seconde) mais la plupart du temps, j'avais uniquement un message m'indiquant une insuffisance de ressources avec retour direct au prompt.

Les tests glxgears ne sont pas nécessairement très fiables (https://wiki.archlinux.org/index.php/Be ... nchmark.29 ou voir intro (fr): http://doc.ubuntu-fr.org/classement_glxgears).
Sinon, de ce que j'en ai vu, le pilote nouveau a été réécrit pour la branche 3.7 (http://linuxfr.org/news/sortie-du-noyau ... 3-7#toc_21). Effet collatéral, régression temporaire ? (de toutes manières, ta carte est une ancienne série c'est vrai, sans 3d il me semble, donc bon, nv peut suffire effectivement)

[mimile]

Merci pour tes explications.

Si je m'en réfère à l'article que tu me renseignes, les modifications apportées à nouveau ne conviennent pas (plus ?) à ma vieille carte graphique, ce qui expliquerait les messages du genre "hors de portée" apparus dès l'installation du premier noyau 3.7.n

Cela dit, effectivement, ma vieille carte ne dispose pas de la 3D et je ne constate pas de différence entre Arch 3.6.11 fonctionnant avec nouveau et Arch 3.7.n fonctionnant avec NV.