Reprise du message précédent :

   
 
Moi de même    
 
Et hop un système fonctionnel 'booté' en moins de 10 sec. avec juste les modules qui vont bien  

Oui mais bon pour l'automount avec gnome-volume-manager par exemple, c'est galère

Bon effectivement, c'est vrai que pour toutes les fonctions d'insertion/détection auto de périph ou medias c'est galère sans hotplug/udev
 
Perso j'ai viré les deux parce que je n'en tirais aucun bénéfice :  
- je n'utilise pas d'environnement de bureau comme Gnome ou KDE, mais un simple WM avec le minimum requis à ce niveau
- j'ai toujours une console à portée de clavier, deux alias pour zsh: 'mntcd' / 'umntcd' et hop je gère mes cdrom/dvdrom
- je n'utilise pas ou très rarement de périph externes (disque usb, zip, cameras, etc)
 
 
hotplug/udev c'est vraiment pratique avec les périph amovibles qu'on branche fréquemment sur son ordi ; si on a une config 'figée' ou qui n'acueille que ponctuellement ce genre de périph, amha je trouve l'intérêt limité vu le tas de paquet/utilitaires requis pour cela (hotplug, udev (bon maintenant ça regroupe les deux), hal ou gamin, etc.) sans compter que cela va en plus interférer sur la gestion d'autres périphs 'fixes' (ex interfaces réseaux), les modules du noyau... bref moi ce côté fourre-tout ou truc à tout faire (c'est un maximum polyvalent mais les choses ne sont vraiment bien gérées qu'à moitié la plupart du temps), désolé j'accroche pas des masses...
 
Un exemple à la con qui m'est arrivé avec hotplug : il gère au boot la détection des interfaces réseaux, bon plus à ce soucier du fichier de conf, du/des module(s) à charger, bref jusque là super. Un beau jour j'ai besoin de relancer le réseau, plutôt que d'avoir à tout rebooter, je fais un rapide /etc/init.d/networking restart et là, plus d'interfaces réseau ; génial: je me rend alors compte que hotplug est appelé lors du boot pour initialiser les interfaces réseaux mais plus lorsqu'on redémarre seulement le daemon chargé du réseau.
 
Ma conclusion : lorqu'un utilitaire n'automatise qu'à moitié ce genre d'opération, autant le virer et tout gérer soi-même de a à z. Si c'est pour avoir à repasser derrière et devoir vérifier systématiquement qu'un utilitaire a entièrement fait son boulot, on perd trop de temps. C'est le même débat qu'avec les interfaces user-friendly sensée automatiser bon nombre d'opérations. En théorie c'est souvent génial, super-pratique, agréable à l'oeil, etc. mais lorsqu'on se rend compte que c'est pas tout à fait au point, voire que celles-ci se mettent à carrément déconner, qu'au final on se retrouve à devoir pister quels fichiers de conf ont pu être mal modifiés par ex, puis devoir les retoucher soi-même, etc. où est l'intérêt par rapport à la série de bonnes vieilles commandes qu'on aura directement tapées dans un terminal ?

Moi je serais toi, en bon geek feignant, au lieu de taper "umntcd", je taperais "eject"

Salut tout le monde.
 
J'ai trafiqué un peu hotplug dernièrement (je voulais le virer vu que udev fait le boulot maintenant, mais en fait que dans sid pour l'instant). Et j'ai vu que udev dépend de hotplug donc je l'ai remis.
 
Sauf que maintenant je me rend compte que quand je lance timidity (serveur d'émulation midi) il me mets un message d'erreur comme quoi il me manque le périphérique /dev/snd/seq .
 
Après recherche c'est le module snd-seq qui n'étais pas chargé.
 
Sauf que avant je n'avais pas à le charger moi même, ni à le mettre dans /etc/modules.
 
Mon problème est lié à hotplug ou pas d'après vous

 
tout pareil

http://www.le-vert.net/divers/gnome-kfreebsd.png < trop fort

 
j'ai l'impression qu'aptitude 0.3.5 est plus rapide
rien que quadn j'upgrade sans paquet à mettre à jour, ça va plus vite (même si ça reste lent) :

tu ne l'as jamais installé ?  peut être qu'il met ce message même pour ceux qui ne l'on pas, à titre d'information (mais je pense quand même que tu as du l'installer un jour)
 
 

rm /dev/.udevdb
 

tu as bien le support du tmpfs dans ton kernel ? Tu as essayé ce qu'il te dit : un dmesg | tail ?

 
si je l'avais mis, il l'a viré tout seul, mais meme apres avoir fait des apt-get remove --purge udev && apt-get install udev il me met ce message
 
 

 
 
j'avais essayé et c'est le meme probleme
 
 

 
j'ai pensé à ca, mais j'ai pas trouvé dans le kernel, j'ai rien a part des info des montages samba  avec la commande

merci, je n'avais pas le support tmpfs dans mon noyau, je l'ai et j'ai plus ce probleme.
 
sinon j'ai un warning au boot concernant /etc/modprobe.d/, il me dit que les fichiers de ce repertoire vont etre ignorés, je peux l'effacer ?

c'est hotplug qu'il faut purger, pas udev
dpkg --purge hotplug
quoiqu'il en soit, que je sache, c'est uniquement un conseil, je pense pas que laisser la conf hotplug sur ton systeme va le géner
 

find /dev -name ".udevdb"
j'ai déjà eu ce probleme mais je sais plus comment je l'avais résolu
je me demande si ce fichier n'est pas présent dans /dev avant le montage par udev
essaie de démarrer depuis un livecd et va voir ce qu'il y a dans /dev si tu trouves pas le fichier avec find (il doit bien être quelque part)
 

tmpfs est dans la catégorie "pseudo filesystem" nommé "Virtual memory file system support (former shm fs)"
EDIT et bien je vois que tu viens de trouver ...

 
surement pas !  
tu utilises un kernel 2.6 ?
si non, laisse ce répertoire tranquille, un jour tu utiliseras un 2.6 et tu en auras besoin
si oui, je pense qu'il y a un probleme, donne le message exact

j'ai un 2.6.13.4
 
j'arrive pas a trouver les log du message de boot dans /var/log
 
c'est lequel ?

 
dmesg | less  
 
 

nan y a pas toutes les info du boot

tu redémarres et tu notes à la main  

vous avez quoi comme valeur dans /proc/interrupts ? (un petit copie colle, merci)
et quel kernel vous utilisez ?

damien@portable:~$ cat /proc/interrupts
           CPU0
  0:     726288          XT-PIC  timer
  1:       1601          XT-PIC  i8042
  2:          0          XT-PIC  cascade
  9:          7          XT-PIC  acpi
 10:      91133          XT-PIC  ohci_hcd:usb1, eth0
 11:     173845          XT-PIC  yenta, ALI 5451, radeon@pci:0000:01:00.0
 12:        111          XT-PIC  i8042
 14:      27260          XT-PIC  ide0
 15:      25840          XT-PIC  ide1
NMI:          0
LOC:          0
ERR:          0
MIS:          0
 
 
 
kernel 2.6.13.4

 
merci
 
moi j'ai ça :

c'est démarré que depuis 20 minutes
et je trouve les valeurs assez élevées
notamment pour eth0, mais surtout pour ide1 où il n'y a qu'un lecteur cd qui n'a pas fonctionné depuis le démarrage du pc
je me poserais pas la question si le pb ne se resumait qu'à des valeurs étranges, mais dans le même temps, j'ai des jeux qui rament depuis quelques jours et je ne vois pas pourquoi, alors je me suis dit que ça pouvait être lier

Vous passez l'option noapic au boot ?

avec noapic
 

C'est un choix noapic ou ca vous posait des problèmes ?
 
J'ai mon horloge qui va trop vite dès que je touche à la fréquence cpu, je sais que noapic me permettrais de régler ca mais j'avais déjà réussi sans désactiver l'apic (je ne trouve plus comment, un coup de bol ).
 
J'hésite à le désactiver.

moi non, c'est pas l'apic mon pb
 
 
laisser moi deviner un truc :
dam1330 et chaced vous utilisez hal, et madkat non, n'est ce pas ?

oui j'ai HAL

Sur certains système les options 'apic' / 'lapic' (ou 'local apic') / 'apic I/O' sont mal supportées et font généralement planter le noyau dès son initialisation ; on se rend souvent assez rapidement compte quand une machine ne supporte pas la gestion apic (c'est au niveau du chipset et du bios employés que cela joue). J'ai aussi vu que certains conseillais de désactiver l'option 'preempt' (ou 'preemptible kernel') pour réduire les risques d'instabilité : bof, de mon point de vue j'ai fais des tests avec ou sans et sur un bon nombre de machines avec chaque fois des versions différentes de noyau, vraiment aucun problème de ce côté là.
 
Pour en revenir à tes problèmes d'horloge, amha je ne pense pas que la gestion apic puisse être vraiment incriminé là-dedans ; la gestion apic permet surtout d'avoir une plage étendue d'IRQ pour adresser les entrées/sorties sur les différents périphs. A l'origine c'est utile pour les systèmes SMP, mais avec l'augmentation du nombre de périph dans n'importe quel PC de base et les problèmes fréquents de collisions et conflits de ressources, les constructeurs et développeurs ont jugé bon de l'intégrer aux systèmes uniprocesseur. En général sur un système pas trop moisi, la gestion apic permet d'éviter plus de problèmes quelle n'en créée.
 
S'il s'agit d'un problème d'interruption que tu rencontres, il faudrait plus voir cela du côté des timers gérés par le noyau (RTC, HPET, HZ, jiffies, etc.). A ce niveau les changements se font sentir entre les versions du noyau (à partir du 2.6.13 l'horloge d'interruption est configurable et l'intervalle de temps (définie par la variable HZ) a été réduit pour l'architecture x86 -cela joue sur la gestion et la consommation de l'énergie par ex. d'avoir des cycles d'interruption réduits). Regarde du côté de google à ce niveau, peut-être que tu pourras trouver des éléments de réponse, bien qu'il faut l'avouer, le problème des timers est complexe.
 
 
Sinon pour info :

Je pense bien que mon problème viens de l'apic, j'ai déjà fait un topic la dessus :
 
http://forum.hardware.fr/hardwaref [...] 0826-1.htm
 
Un lien qu'on m'a donné qui concerne exactement mon matériel (mais la solution proposée ne marche pas) : http://www.ussg.iu.edu/hypermail/l [...] /1505.html
 
Et encore un exemple : http://forum.hardware.fr/forum2.ph [...] y=0&nojs=0
 
C'est vrai que ca parait bizarre à priori, mais l'apic peut générer des problèmes d'horloge

 
+1, hal et udev
 
En fait, l'apic est désactivé en dur dans mon noyau, et j'ai oublié de le réactiver  

http://incoming.debian.org/apt_0.6 [...] 86.changes

 
finit les gros dl. Quand on a une petite connection, c'est appréciable

 
ca marche comment ce truc

 
c un initrd++ utilisé par Ubuntu.
avant j'avais ts les modules ide-disk chargés (via, piix,...) avec initrd et ça m'énervait.
 
 et maintenant debian va y passer pour les prochains kernels.

Faut activer bootlogd pour ça.

bon, je sais pa comment ça se fait mais depuis que j'ai redémarré Xorg hier soir, le son marche plus beep-media-player me sort l'erreur habituelle "veuillez vérifier que vous avez choisi le bon plugin de sortie etc etc ..."
évidemment j'ai vérifié et c'était bien sur alsa quand je mets esound ça plante aussi, et OSS le son est *horrible* (comprends po pkoi d'ailleurs ...)
 
brayf si quelqu'un a une solution

Je viens de passer ma debian en unstable    
 
Petite question : vous arrivez à faire marcher le moteur gstreamer de kaffeine ?
Et pour ceux qui y arrivent qu'est-ce qu'il apporte par rapport au moteur xine ?
 
Chez moi ca me dit "impossible de charger gstreamer-part".

 
Bienvenue chez les hommes

  Bieng !
 

personne pour mon problème de son ?  

Perso (ça n'engage que moi ) je trouve que la lecture multimédia avec gstreamer (quelque soit le frontend, c'est gstreamer qui est bien souvent la source de pas mal d'emmerdes) est laborieuse. En plus de fonctionner approximativement (voire pas du tout) il nécessite d'installer un certains nombre de paquets (je ne parle pas les libs/codec pour la lecture -ex: totem-gstreamer : une quinzaine de paquets sont automatiquement installé avec, totem-xine : 4 paquets sont automatiquement installé avec)...
 
Il y a plein d'exemples de dysfonctionnement avec gstreamer que ce soit sous Sarge ou Sid d'ailleurs : Totem basé sur gstreamer plante parfois sans raison (vu sur 2 installs de Sarge différentes) avec les mêmes config/machine et sur la même vidéo Totem basé sur Xine ne pose aucun problème (faut m'expliquer). Le même problème m'est arrivé sous Kaffeine/Gstreamer avec la lecture de DVD qui s'arrête (ça ne plante pas, la lecture s'arrête tout simplement) après un temps de lecture supérieur à 2h (aucun stress avec un autre moteur de lecture   )...
 
 Je n'ai jamais eu le moindre souci avec les lecteur basé sur Xine, et je connais pas mal de potes qui sont du même avis que moi si on doit faire une comparaison Xine/Gstreamer (de même les renégats derrière mplayer ont fait un meilleur boulot que les mainteneurs de Gstreamer du point de vue qualité/performance/stabilité en lecture vidéo pure amha). Bref, peut être qu'il y a des fonctionnalités supplémentaires avec Gstreamer (j'avoue ne pas m'être penché en détail dessus, j'ai bien vite eu ma dose avec), mais déjà avoir un lecteur qui lit simplement ses fichiers sans déconner c'est un minimum, en cela Xine c'est le bien  

C'est survenu comme ça du jour au lendemain sans raison ou après une mise à jour (logiquement dans ce cas là c'est sans doute un bug dans un des paquets mis à jour) ?

 
J'aime bien xine, je l'utilise dans amarok et kaffeine, mais comme gstreamer est une nouveauté pour kaffeine j'étais curieux, puis c'est aussi parcequ'il y a de rares videos qui passent mal avec kaffeine (xine) que je lis avec vlc.
 
Enfin bon au revoir gstreamer !
 
fabetal > tu peux peut-être commencer par un alsaconf, tu n'aurais pas changé de noyau récemment ?