[udev] tty non disponibles

[MCMic]

Bonjour,

Lorsque je switche vers un TTY après avoir démarré (ctrl+alt+F*), je tombe sur la séquence de démarrage bloquée sur le message "waiting for uev events to be processed".

Lorsque je souhaite éteindre l'ordinateur, même soucis, au lieu de s'éteindre, il affiche le même écran que les TTY, et je suis obligé de forcer l'extinction au bouton.

Des idées sur l'origine du problème?

[widapit]

Salut !

Des idées sur l'origine : non . mise à jour de udev ??!
sinon un oeil dans les logs pourrait aider ...
"cat /var/log/boot" "cat /var/log/pacman.log" "cat /var/log/messages.log", ou même "cat /var/log/everything.log | grep udev"

[MCMic]

"cat /var/log/boot" ne montre pas le problème car la séquence de boot du tty graphique fonctionne jusqu'au bout, et c'est celle là qui est logguée dans ce fichier d'après ce que j'y lit.

"cat /var/log/everything.log | grep -i udev" me donne juste:
Apr 23 16:39:49 localhost [ 0.792136] udevd[37]: starting version 181
Apr 23 16:39:49 localhost [ 6.603471] udevd[141]: starting version 182

[MCMic]

Je ne sais pas si c'est lié, mais je me suis aperçu que j'ai "ksoftirqd/0" et "ksoftirqd/1" qui squattent une bonne partie de mon processeur également.

[GuilouV]

Il y a quelques temps traînait un sujet similaire avec un temps de latence long de udev (je n'ai pas retrouvé le sujet sur le forum français mais en voici un en version anglophone : https://bugs.archlinux.org/task/28154).
Si tu as une carte wifi realtek ton problème est peut être lié.
Si c'est le cas il te suffit de modifier la ligne MODULES du /etc/rc.conf :

Code : Tout sélectionner

MODULES=(rtlXXX)

où rtlXXX est le pilote de ta carte wifi.

[MCMic]

J'ai essayé cette solution, "lspci -vin -s" me donne "b43-pci-bridge", j'ai ajouté "b43" à MODULES, parce que b43-pci-bridge il ne connais pas.
Ça ne résout pas mon problème :-/

Ce qui me gène le plus maintenant c'est ksoftirqd/0 et ksoftirqd/1 qui bouffent une partie du proco en permanence…
J'arrive pas non plus à en trouver la cause.

[MCMic]

Bon, finalement mes problèmes sont partis en ajoutant "nomodeset" à ma ligne grub.
J'ai vu que c'était demandé par catalyst lors d'une mise à jour donc je l'ai fait.

Par contre j'ai une résolution pourrie sur mes tty :-/

[jeangab37]

Pour la résolution en tty en ajoutant vga=773 ou vga=ask le chiffre qui convient à ta résolution dans GRUB tu devrais régler le problème.

Voir le merveilleux wiki de notre distribution, en anglais ils en parlent dans la section framebuffer, en français j'ai pas vu.

Grub

EDIT: Je viens de repenser à ça et il me semble que le framebuffer de grub n'a plus rien à voir une fois sorti du grub shell... J'aurai essayé!

[benjarobin]

Tu mélange en effet le shell de Grub et le framebuffer du kernel, mais ce que tu dis est juste. Tu ajoutes vga=ask à la fin de la ligne kernel (Donc aucun rapport avec Grub)

[FoolEcho]

@jeangab37: je pense que ça n'a rien à voir en effet.

[HorsSujet]
Mais c'est plutôt là-dessus que je voulais réagir:

Pour la résolution en tty en ajoutant vga=773 ou vga=ask le chiffre qui convient à ta résolution dans GRUB tu devrais régler le problème.

Voir le merveilleux wiki de notre distribution, en anglais ils en parlent dans la section framebuffer, en français j'ai pas vu.

C'est une section que j'avais pensé rajouter et que je n'ai jamais fait pour ne pas «confusionner» l'utilisateur... et moi-même car j'ai un doute et je n'ai pas approfondi plus que ça... Il me semble que lorsque tu as kms d'activé (par défaut c'est le cas avec intel, nouveau ou ati), l'option vga ne sert à rien (je crois qu'il faut soit laisser le pilote décider, soit passer par video=). Il n'y a que pour nvidia que ça serve vraiment (ou avec le pilote générique vesa).

... vu que benjarobin est là, il pourra peut-être éclaircir ce point...
[/HorsSujet]

[benjarobin]

Pour faire un résumer au plus simple et surtout pour ne dire que ce que j'ai compris :
Il existe 2 moyen d'avoir une console via les tty :
- Le classique et ancien framebuffer qui est aujourd'hui incompatible avec la majorité des drivers libres. Les drivers propriétaires (Catalyst et Nvidia) reste compatible avec ce framebuffer...
Pour forcer l'utilisation de ce framebuffer il faut utiliser l'option nomodeset qui interdit le chargement de KMS
Pour changer la résolution, il suffit de passer comme paramètre au kernel l'option vga=...

- KMS : Il est requis par les drivers libres. Il existe une option pour changer la résolution, (video=) mais celle-ci n'est pas ou peu documenté voir non implémenté dans les drivers.
L'utilisation de l'option vga= est en conflit avec KMS, elle ne doit pas être utilisée.

Avec l'arrivée de Bumblebee qui maintenant arrive à faire cohabiter les drivers intel (nécessite KMS) et le driver Nvidia (Que je croyais incompatible avec KMS : Il ne l'est plus ?), je suis personnellement assez perdu...

[FoolEcho]

@benjarobin: il ne me semble pas que nvidia supporte kms en effet (c'est l'une des raisons d'être du pilote libre d'ailleurs)... donc, effectivement, côté bumblebee, je ne pourrais pas dire, je suis comme toi là-dessus, je n'ai que constaté ce support du pilote proprio (et c'est tant mieux).