mig73
Bonjour, la distribution utilisée est une FC6 2.6.18-1.2798, platform i686.
Je souhaite utiliser 2 cartes PCI (une carte I/O et une carte RS422 pour info)
Ces deux cartes fonctionnent parfaitement sur un système embarqué, basé sur la meme plateforme hw mais avec un OS bcp plus réduit (kernel 2.6 et systeme de fichier minimal)
Je souhaiterai donc les utiliser sur un systeme plus complet avec cette distribution (pour disposer d'un environnement graphique notamment...)
Lorsque je connecte l'une ou l'autre (ou les 2) des cartes PCI, le système se bloque au demarrage, lors du lancement de udev.
Je vous passe les erreurs pour le moment car il y en a plusieurs pages et je ne connais pas de moyen de les recupérer...
En cherchant un peu sur le forum, j'ai rencontré plusieurs sujets qui traitaient des probemes de udev, mais
ils se resolvent en desactivant apci, qui ne semble pas repondre a mes problemes (PCI)
Si j'essaye de stopper le lancement automatique de udev (#start_udev dans /etc/rc.d/rc.init )
le demarrage bloque sur le lancement du HAL dameon.
Je recommence alors l'operation en mode interactif, en evitant de charger ce daemon.
Le systeme refuse alors de demarrer le serveur X, car il manque /dev/mem (qui apparemment doit etre
créé lors du udev)
Parcontre, les deux cartes, une fois leur driver chargé etc, fonctionnent (a peu pres) convenablement,
ce qui plutot un encourageant...
Quelqu'un peux il m'apporter de l'aide ?
Plus précisemment, est il possible de lancer le serveurx malgré que udev n'ait pas été lancé ?
Plutot que de ne pas lancer udev, et risquer de ne pas creer des devices necessaires (comme c'est le
cas pour startx) est il possible de parametrer udev, de maniere a ce qu'il laisse les deux cartes sans
essayer de les installer ( possibilité de bloquer la recherche de nouveaux periph sur le bus PCI ?? )
Pour info le repertoire /etc/udev/rules.d contient les repertoires suivants:
05-udev-early.rules
40-multipath.rules
51-hotplug.rules
60-libsane.rules
60-net.rules
60-pcmcia.rules
60-wacom.rules
90-alsa.rules
90-hal.rules
95-pam-console.rules
Toutes vos idées sont vraiment les bienvenues !
Merci
mike_x
Depuis 1 mois tu dois te sentir seule.
Bon moi aussi je me bagarre avec udev, j'aime pas le XML et pis j'ai régulierement des regressions.
En ce moment et depuis un mois je n'ai plu le montage dynamique des periph usb. Je monte à la mains mais ca me saoul ! Car si je montre ca à des windoziens, c'est pas bon pour nux !
Bon pour ton histoire, je suis loin de maitrisé parfaitement udev, mais je peux te proposer 2 axes de recherches. §tiliser une vieille distrib qui n'implemente pas udev et utilise un module par periph donc c'est toi qui décide de ce que tu veux monter car c'est clairement explicite. Je crois que udev est apparu sur la FC5 mais à verifier.
Sinon il y a un binaire qui s'appelle /sbin/udevd.static peut etre que ce démon necessite une conf manuel mais n'a rien de dynamique, sinon il te faudrait commenter dans le /udev/rules.d le type de materiel qui pose probleme lors du monatge automatique ensuite faire un script de montage spécifique que tu lanceras avec /etc/rc.d/rc5.d/S99local
Bon courage
Mike_x
mig73
Bonjour Mike,
effectivement je me sents un peu seul, les réponses obtenues sur les autres forums (notamment internationaux) où j'ai également posté, m'ont invité a remettre a jour ma distrib' ou installer FC7, des trucs dans le genre... des réponses comme celles-ci sont un peu regrettables dans le sens où visiblement il y a peut etre une defaillance, ou une amélioration a apporter puisque le matériel n'est pas accepté. Personnellement, ca me pose problème car c'est un projet important et qui aurait permis de convaincre mes dirigeants de parier sur Linux pour de futurs projets. Désormais, difficile de rester crédible en leur disant que les distribs de nos jours n'ont rien a envier a Windaube... (tu sais sans doutes comment sont les mentalités des vieilles instances dirigeantes, très difficile a faire evoluer...)
C'est sans doutes une goutte d'eau dans la mer, et la tendance actuelle semble en faveur a l'expansion de Linux en industrie, mais tu sais ce qu'on dit, une goutte après une autre...
Personellement, ca ne change en rien mon affection pour la communauté Linuxienne et le monde de l'open source, et je n'oublie pas que par le passé, certaines personnes me sont venues en aide, en partageant leur savoir.
Revenons au sujet en question:
Pour le premier axe de recherche, "utiliser une vieille distrib qui n'implemente pas udev et utilise un module par periph donc c'est toi qui décide de ce que tu veux..." j'ai eu globalement la meme reflexion. Sans utiliser veritablement un vieille distrib, j'ai utilisé le système Linux utilisé sur la cible sur laquelle je travaille (pour info c'est ELinOS, un truc qui marche pas mal dans l'embarqué et plutot pratique ). Sur ce système pas de udev, et j'ai l'avantage que tous les drivers tournent directement. En contrepartie, il est diffcile d'obtenir un serveur X embarqué, j'ai egalement une lib gtk trop obsolète, et des soucis des crosscompilation pour des drivers a venir bref, il reste du pain sur la planche. Tu comprens pourquoi il aurait été interessant de pouvoir implémenter tout cela sous Fedora, j'aurai éviter de réinventer la roue...
Pour le deuxième axe, je me suis pas trop frotté à udev. J'aurai bien voulu indiqué a udev de ne pas scrutter sur le bus PCI, bus sur lequele se situe mes 2 cartes qui posent problemes, mais COMMENT ???
Si quelqu'un peut me donner un indice...
Merci Mike, et bon courage a toi aussi !
Anvil
Laisse tomber la piste udev. Udev est une consequence, pas une cause directe. Il est plus probable que ce soit un probleme d'acpi, ou de driver pour tes cartes.
