Udev sa freinent mon boot

Support Debian
#1

Hello

bon je me suis installer une version 64 bits (je re-tente pour la 5eme foit:p) et j’ai ces message qui son
1 question qui gène vraiment sa sarète la durant aux moin 5 sec on dirait presque que le pc a freezer … bref udev me re-casse les pieds :013
bon je google mai tout les info que je trouve date, et son amha plus actualité

2 pas joli c’est écrit en gros on pourrait peux être faire mieux(mai priori ter a la question 1) ?

bon raler c est bien mai voila les nouvelle information :slight_smile:

installation sur un ssd tout neuf :041 je ne sai pas si sa a son importance mai bon.

dpkg -l |grep udev
ii  libgudev-1.0-0                       160-1                          GObject-based wrapper library for libudev
ii  libudev0                             160-1                          libudev shared library
ii  udev                                 160-1                          /dev/ and hotplug management daemon
uname -a
Linux ssd 2.6.32-5-amd64 #1 SMP Wed Aug 25 13:59:41 UTC 2010 x86_64 GNU/Linux
  • le screenchot ci joints pris durant le boot (bon peux pas enlever le flash sinon on vois rien…

#2

Pour le dernier messages, il te faut modifier une des règles udev. Fais un grep -r uinput dans /etc/udev

Pour les warning, c’est une clarification de la syntaxe des règles udev. Tout ça n’a rien à voir avec le gel. Je te suggère de regarder

  1. Si tu n’as pas des règles persistent-net qui te mettent une interfaces eth1 ou eth2 en contradiction avec ton fichier interfaces
  2. Ton DNS
  3. Ton /etc/hosts
#3

[quote=“fran.b”]Pour le dernier messages, il te faut modifier une des règles udev. Fais un grep -r uinput dans /etc/udev

Pour les warning, c’est une clarification de la syntaxe des règles udev. Tout ça n’a rien à voir avec le gel. Je te suggère de regarder

  1. Si tu n’as pas des règles persistent-net qui te mettent une interfaces eth1 ou eth2 en contradiction avec ton fichier interfaces
  2. Ton DNS
  3. Ton /etc/hosts[/quote]

Merci pour ta réponse :006

voila les details

cat /etc/hosts
127.0.0.1       localhost
127.0.1.1       ssd.lan ssd

# The following lines are desirable for IPv6 capable hosts
::1     localhost ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters

ls /etc/udev/rules.d/ 025_libgphoto2.rules 70-persistent-cd.rules 70-persistent-net.rules z60_hdparm.rules

cat 70-persistent-net.rules
# This file was automatically generated by the /lib/udev/write_net_rules
# program, run by the persistent-net-generator.rules rules file.
#
# You can modify it, as long as you keep each rule on a single
# line, and change only the value of the NAME= key.

# PCI device 0x10ec:0x8168 (r8169)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="90:e6:ba:3c:51:c1", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"
 cat /etc/network/interfaces 
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
allow-hotplug eth0
iface eth0 inet dhcp

pour un cd /etc/udev && grep -r uinput
on dirait que sa tourne dans le vide :017

mon clavier utilise un uinput il me semble :017 :108

find / -iname uinput
/dev/uinput
/dev/input/uinput
/sys/devices/virtual/misc/uinput
/sys/class/misc/uinput
/sys/module/uinput

si tu as une idée je suis preneur :slight_smile:

#4

bon j’ai repérer le fautif

udev y est pour rien on dirait le vrai coupable c’est ACPI j’ai juste ?

ha non voila autre chose:

cat /etc/modules 
# /etc/modules: kernel modules to load at boot time.
#
# This file contains the names of kernel modules that should be loaded
# at boot time, one per line. Lines beginning with "#" are ignored.
# Parameters can be specified after the module name.

loop

# Generated by sensors-detect on Thu Sep 16 04:42:31 2010
# Chip drivers
coretemp
w83627ehf

lm-sensors est le coupable
je vai voir si je surprime le chargement du module sa marche mieux :stuck_out_tongue:

#5

le uinput, cherches le dans les règfles sous /etc/udev:

grep -r uinput /etc/udev

#6

sa renvoiye rien :017

[code]# grep -r uinput /etc/udev

[/code]

j’ai re-compiler le kernel et virer tout ce qui ressemble a uinput et le strict minimum grace a

make localmodconfig

on dirait que sa va mieux mai sa reste a confirmer car je doit encore tester les périphérique pour voir si tout est reconnu, et essaye de lire les message qui defile a 800 neuds ctr +s arrive a prendre la main trop tard , et voir si je dit pas des conn* …

edit bon sa déconne encore un peux…

on dirait que les règle ce trouve ailleurs :017

grep -R uinput /lib/udev/
/lib/udev/rules.d/50-udev-default.rules:KERNEL=="uinput",               NAME="input/%k"
#7

Ah oui, c’est vrai que des règles ont été déplacées, change la règle en

#8

Concernant tes messages du type: SYSFS{}= will be…, il me semble que le passage (ou l’upgrade, je ne sais plus) de sysv-rc (ou sysvinit…on remarquera la précision de mon message ) avait résolu ce pb qui n’en était pas un (dans le sens ou tout se déroulait tranquillement derrière).

#9

bon alors sa pédale encore mai on dirai que sa vien de l’acpi … ?
c’est fluide j’usqua la première photo


et la sa redemarre ( j’ai forcer l’arret avec ctr + s)

#10

Coucou,

Pour ta 1ère image, j’ai eu le même pb avec mon vieux portable (un amd 1800 + chipstet via) des kernel 2.6.32 au 2.6.34…

Solutionné (pas par moi hein) avec le noyau experimental (2.6.35)

#11

Moi j’ai le PC qui plante avec un son strident en continu lorsqu’il arrive sur le udev au demarrage :
Waiting for /dev to be fully populated

Ca ne le fait que sur Debian. Sur Arch,Fedora ou autre OS, tout fonctionne correctement.
J’ai ce problème dès que je passe en 2.6.35.

J’aimerais testé en 2.6.32 de Sid mais sur ce noyau, je n’ai pas de reseau via Ethernet donc bon…

#12

Mais as tu une base de comparaison pour dire que ça rame? Parce que 2s pour initialiser les périphériques, ça me parait tout de même normal pour peu qu’il y ait des firmware à envoyer ou des trucs de ce genre.

#13

[quote=“zodar”]Coucou,

Pour ta 1ère image, j’ai eu le même pb avec mon vieux portable (un amd 1800 + chipstet via) des kernel 2.6.32 au 2.6.34…

Solutionné (pas par moi hein) avec le noyau experimental (2.6.35)[/quote]

alors j’ai tester :slight_smile:
le messaye n’y est plus mai sa pedale toujours aux même endroit ,je pense que ce qui ta tromper c est que le message a été suprimer. c est vrai que sur un disque len sa ce vois moins facilement :slight_smile:

bref sa doit venir de quelque chose mai j’arrive pas a trouver ce que c est …

#14

Hm… merci pour l’info, je regarderai :wink:

Faut dire que j’l’ai pas allumé depuis que j’ai mon nouveau petit jouet :118

#15

Moi, j’ai trouvé d’ou venait mon bruit strident continuel. Il vient en faite de la sortie des Hauts-Parleurs si j’active la sortie “Front Mic Boost”.

Si cette sortie est activée et que je démarre directement sur Debian : Rien
Si elle est activée et que je reboote sur Debian après être allé sur 7 : Ca sonne.

Bref, l’ai complètement désactivé.

Je post içi car je croyais que cela venait du bogue actuel d’udev en Sid :005

#16

oui sur mon portable sa rame pas :slight_smile:
même config mai en 32, par contre que ce soie en 32 ou en 64 sur le pc fixe sa reste pareil. je vai voir pour installer un truc qui log le boot sa devrai aider a y voire plus claire

Bon avec bootchart pris dans les depot de la sid j’ai du ajouter la ligne qui va bien a grub …

bref 1 ere image j’ai virer tout les deamon qui traîne sauf ceux du clavier. celui ci je les lasser booter sans rien faire le temps de boot semble un peux court pas rapport a la montre en main environ (7 seconds en +)
le but étai de voir si un demon ne serai pas la source du problème le seul problème vidria a ce moment la du clavier… m’étonnerai mai bon…

la 2 eme j’ai fait 1 ctr+s juste aux moment ou sa rame. et un autre un peux plus tard.

on peux y voir 3 truc qui pourrait être en cause.
en 1 ifup ? mise en route du reseaux ? je pencherai pour cette cause ?
en 2 je placerai, modprobe un module donc mai quoi ?
en 3: startpart ? peux etre que c est bootchart qui inscrit cela, mai j’ai pas de processus qui devrai faire partie de cette catégorie.
en 4 sleep et dhclient ??

je pense qu’il me faudrai regarder du coter du reseau ,l’ip est attribuée par le routeur, je vai voir si je peux pla mettre une ip static :slight_smile:

[edit] reseau hors de cause.
bon ben sa vien du clavier visiblement grr.
c’est pile quand le lcd du clavier s’alume et comme ce clavier n’existe pas sur le portables logique que sa passe sans problème.
et a ce moment la il doit surment charger un module usb

je clore le sujet car amha, je pense que je peux rien faire a par changer de clavier… si je trouve le module dans le kernel je pourrait peut etre le mettre en chargement permanent.

#17

startpar est ce qui lance les scripts en parallèle. ifup lance dhcleint et attend la réponse ce qui prend en général 1 à 2s. Dans ton schema, c’est ifup qui semble prendre du temps dans ton poremier graphe.

#18

En regardant mieux, on s’aperçoit que hal, cups, acpi-fakekey, rsyslogd, cron, ntpd, dbus, ulog, ssh, avahi et exim4 ne sont pas démarrés lors de l’attente. En regardant de quoi ils ont besoin, tu peux savoir où ça coince.

Sinon fais un truc du genre

echo "Debut de "$NAME

echo "Fin de "$NAME au début et à la fin de chaque script suspect de /etc/init.d, tu sauras le coupable. Eventuellement regarde le lsmod ou bien met udev en verbeux.

#19

[quote=“fran.b”]En regardant mieux, on s’aperçoit que hal, cups, acpi-fakekey, rsyslogd, cron, ntpd, dbus, ulog, ssh, avahi et exim4 ne sont pas démarrés lors de l’attente. En regardant de quoi ils ont besoin, tu peux savoir où ça coince.

Sinon fais un truc du genre

echo "Debut de "$NAME

echo "Fin de "$NAME au début et à la fin de chaque script suspect de /etc/init.d, tu sauras le coupable. Eventuellement regarde le lsmod ou bien met udev en verbeux.[/quote]
+1 je vai matter :slight_smile:
merci pour l’idée

#20

Où tu en es?

As tu regardé les temps donnés par dmesg pour voir si un périphérique ne coincait pas?