Forum Linux.debian/ubuntu xserver-xorg-video-intel avec KMS_écran noir au boot

Posté par  .
Étiquettes : aucune
1
6
nov.
2010
Bonjour
Dans Squeeze fin octobre, UMS a été retiré de xserver-xorg-video-intel au profit de KMS (kernel mode setting):

Le Changelog qui a foutu le bazar:
xserver-xorg-video-intel (2:2.12.0+shadow-2) unstable; urgency=low

* UMS is gone, this means Linux-only (closes: 597845).

-- Julien Cristau <jcristau@debian.org> Thu, 23 Sep 2010 16:40:26 +0200

Matériel concerné: chipset i915 sur carte mère Intel (sur un portable)
noyau compilé à partir du paquet source debian/Squeeze 2.6.32-27

Très bien, mais tout cela donne un bel écran noir lors du boot.
Si je ne veux pas de cet écran noir, je ne compile pas le noyau avec le module i915.
Dans ce cas j'obtiens en essayant de lancer X
'module i915 not found'

Ce que dit la doc du paquet Debian:
xserver-xorg-video-intel (2:2.9.1-2) unstable; urgency=low
Starting with this version, the intel driver enables kernel mode setting
(KMS) by default for 830 and later chips. This comes with a framebuffer
driver which enables native resolution on the console. KMS also allows
faster VT switching and mode changes, as well as e.g. DisplayPort support.
In case of trouble KMS can be disabled with the 'nomodeset' kernel command
line parameter, or by editing /etc/modprobe.d/i915-kms.conf.


J'ai essayé de mettre dans /etc/modprobe.d/i915-kms.conf
'options i915 modeset=0' au lieu de 1
=> au boot 'module i915 not found'
ou de passer l'option 'nomodeset' à la fin de la ligne concernant le boot/kernel dans grub
Aucun résultat
Quelqu'un a-t-il rencontré le même problème ?
Merci d'avance pour toute piste/lien
M

PS: bizarre d'introduire un changement majeur dans X alors que Squeeze est gelée

Liens:
http://www.mail-archive.com/debian-x@lists.debian.org/msg101(...)
http://wiki.debian.org/KernelModesetting
http://forums.debian.net/viewtopic.php?f=5&t=56550
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=601558
http://wiki.archlinux.fr/xorg/intel/i910

  • # ligne de commande de grub

    Posté par  (site web personnel) . Évalué à 2.

    Dans la ligne de commande de grub, essayer d'ajouter à la fin

    i915.modeset=0

    au lieu de nomodeset.

    Sinon, pour avoir le KMS, bien vérifier dans la configuration du kernel que les supports qu'il faut sont activés, ou essayer avec le dernier paquet du kernel (binaire) de squeeze.

    • [^] # Re: ligne de commande de grub

      Posté par  . Évalué à 2.

      Merci pour la réponse
      i915.modeset=0 règle le problème de l'écran noir mais ne permet pas de démarrer X
      Sinon, tout ce qui concerne KMS et le framebuffer est activé dans mon noyau.
      Tout ceci ressemble à un bug:
      http://wiki.debian.org/KernelModesetting#Intel
      Comme décrit ci-dessus 'acpi=off' évite également l'écran noir mais ne permet pas de démarrer X...

      "L'art est fait pour troubler. La science rassure" (Braque)

      • [^] # Re: ligne de commande de grub

        Posté par  . Évalué à 2.

        En fait, le module i915 (DRM) n'est pas chargé au boot et ensuite un 'modprobe i915' affiche des messages d'erreur 'i915.ko no such a device'. Ce module est poutant bien présent dans /lib/modules

        "L'art est fait pour troubler. La science rassure" (Braque)

      • [^] # Framebuffer

        Posté par  (site web personnel) . Évalué à 1.

        Normalement il faut compiler uniquement le pilote i915 avec le support KMS (en dur de préférence sinon il faut le spécifier dans l'initrd) et le framebuffer (FB = y), mais il il ne faut rien compiler à l'intérieur de la section FB. Est-ce bien ton cas ?

        • [^] # Re: Framebuffer

          Posté par  . Évalué à 2.

          'mais il il ne faut rien compiler à l'intérieur de la section FB'
          J'ai essayé avec plusieurs kernel compilés différemment. Rien ne marche et il semble que je ne sois pas le seul à rencontrer le problème. Exemple:
          http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=600802

          "L'art est fait pour troubler. La science rassure" (Braque)

          • [^] # Re: Framebuffer

            Posté par  (Mastodon) . Évalué à 2.

            Ici une copie de la partie adéquate, si tu veux l'essayer : http://pastebin.ca/1984501 Ceci sur un 2.6.32 (-24-l). Pas de problèmes d'affichage de rien lors du boot. (mais ensuite c'est un Xorg 1.7.7) L'utilité sera très faible, puisqu'au mieux ça marchera pour toi.

          • [^] # Re: Framebuffer

            Posté par  . Évalué à 1.

            Il faut aussi virer du menu de GRUB tous les paramètres au boot relatifs au FB (vga=, video=).

  • # Noyau officiel Debian et autres informations

    Posté par  (site web personnel) . Évalué à 1.

    As-tu essayé avec le noyau compilé par Debian : 
    # aptitude install linux-image-2.6
    Quel est l'extrait de dmesg qui donne l'erreur de chargement de i915? Le log de Xorg ( /var/log/Xorg.log ) donne-t-il quelque chose? Y-a-t-il un OOPS noyau (à éventuellement capturer avec netconsole s'il n'apparait pas dans les logs)?

    • [^] # Re: Noyau officiel Debian et autres informations

      Posté par  . Évalué à 2.

      'As-tu essayé avec le noyau compilé par Debian '
      La question qu'il ne fallait pas poser ....J'ai découvert récemment que le noyau officiel Debian ne boote pas chez moi. Etrange mais c'est comme cela....En fait, je n'ai jamais utilisé de noyau officiel debian, sauf lors de ma première et dernière installation de Debian il y a plus de dix ans. Ce devait être une Debian Potatoe. Donc je compile tous mes noyaux. Ce noyau officiel 2.6.32 refuse de monter le système de fichiers après avoir semé la pagaille dans mon fstab lors de son installation, donc exit. De toutes manières, un noyau officiel ne changerait rien à l'affaire. Le dernier 2.6.32.25 est très stable.

      "L'art est fait pour troubler. La science rassure" (Braque)

      • [^] # Re: Noyau officiel Debian et autres informations

        Posté par  (site web personnel) . Évalué à 1.

        C'est le passage aux UUID qui semble te mettre la pagaille (passage à libata pour les drivers de contrôleur de disque dur qui change les noms de par exemple de hdx à sdy). S'il ne trouve pas le système de fichier racine, c'est à mon avis que ta configuration de grub nécessite une mise à jour.

        En tout cas, si tu veux creuser ton problème, je cois qu'il faut que tu essayes avec le noyau officiel... Ca permettrait d'isoler le problème.

        Et dans tous les cas, tu aurais intérêt à migrer à libata pour tes disque durs, c'est dorénavant la manière de faire dans le noyau vanilla depuis plusieurs versions...

        Pour mon information, car je suis curieux, y-a-t-il une option de la compilation officielle qui te pousse à recompiler toi-même?

        • [^] # Re: Noyau officiel Debian et autres informations

          Posté par  . Évalué à 1.

          Ce paquet plus ancien marche très bien.
          http://snapshot.debian.org/archive/debian/20100514T224948Z/p(...)
          Pourquoi changer ce qui marche ? Pour passer au KMS ? Un KMS pas vraiment stable ni performant d'après ce qui est dit dans les rapports de bugs. En fait ce KMS à déboguer arrive trop tard, en période de freeze et ce n'est pas très cohérent au regard de l'intransigeance des développeurs concernant l'acceptation des nouveautés. Mais bon, certaines choses nous échappent certainement...
          Concernant les noyaux officiels, je ne vois pas leur intérêt. Ils ralentissent le système vu le nombre d'options inutiles activées par défaut. Mieux vaut compiler un paquet source officiel en ne sélectionnant en dur que ce qui est nécessaire.
          'tu aurais intérêt à migrer à libata pour tes disque durs'
          Assurément. Personnellement, le hd de mon PC est un sata mais celui de ma femme (portable concerné par le bug du nouveau xserver-xorg-video-intel) est un ide. Il va falloir que je me penche sur la question, renommer les hd... en sd.. dans Grub, etc .....

          "L'art est fait pour troubler. La science rassure" (Braque)

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.