L'une des 2 (eth0) était générée par le module 'eth1394' qui permet IP
over 1394 (mais, comme le dit la doc, n'émule pas Ethernet), ce qui
fait que c'est la carte SCSI qui préemptait sur DHCP puisque son module
était chargé avant le module de la carte Ethernet.
Si c'est cela, ça peut de régler de plusieurs manières, par ordre de préf perso:
* recompiler un kernel sans le module 'eth1394',
* débarquer le module 'eth1394' par un script exécuté avant le dhcp-client,
ou si impossible, exécuté en dernier et relançant le dhcp-client après coup,
* bidouiller avec HAL pour qu'il inverse l'ordre des modules.
Perso, je n'aime pas le dernier parce que ça touche à une couche plus profonde
(et donc IMHO plus réservé pour faire correctement reconnaître un device
apparaissant comme inconnu par exemple.)
'gade si ce module est présent, si vi, vire-le et relance le client pour voir ce
qui se passe.
---> Malheureusement lsmod ne donne aucun eth1394 comme résultat !...
# lsmod | grep 1394
ohci1394 24944 0
ieee1394 75800 2 sbp2,ohci1394
Qu'en penser ?
Mais, j'ai encore une carte contrôleur SCSI qui "traîne" dans mon ordi... Devrais-je l'enlever pour voir si il se "passe qqch de mieux" ?
Merci de ton aide
Ludovic
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists Vous pouvez aussi ajouter le mot
``spam'' dans vos champs "From" et "Reply-To:"
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Jean-Yves F. Barbier
LM--- a écrit : ...
---> Malheureusement lsmod ne donne aucun eth1394 comme résultat !... # lsmod | grep 1394 ohci1394 24944 0 ieee1394 75800 2 sbp2,ohci1394
Qu'en penser ?
qu'une cause possible vient d'être éliminée :)
Mais, j'ai encore une carte contrôleur SCSI qui "traîne" dans mon ordi... Devrais-je l'enlever pour voir si il se "passe qqch de mieux" ?
non, puisque le module qui pouvait amener le PB n'est pas chargé.
à mon avis, on commence à s'éparpiller: il faut donc reprendre le PB à zéro: * virer/désactiver *tous* les daemons||pgms susceptibles d'interragir, * lancer le client manuellement pour voir si l'exécution est correcte de bout en bout (sans oublier de virer /var/lib/dhcp3/dhclient.leases de façon à n'avoir aucun failover.)
Une fois que cette simple manip fonctionne correctement, on peut envisager de rajouter une pièce par une pièce, en re-vérifiant le bon fonctionnement à chaque étape.
Tu commencer aussi par faire un 1er test en enlevant la carte USB/FW, histoire de voir si ça passe.
Egalement: cat /proc/interrupts pour voir sur quelles IRQs sont affectées les cartes ETH & USB/FW, et éventuellement les inverser physiquement pour voir si le schmilblick est-il vert (si c'est du PCI, les IRQs sont normalement affectées en ordre croissant dans le sens slot AGP vers dernier PCI; pour Xpress, je ne sais pas.)
JY -- X-rated movies are all alike ... the only thing they leave to the imagination is the plot.
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers En cas de soucis, contactez EN ANGLAIS
LM--- a écrit :
...
---> Malheureusement lsmod ne donne aucun eth1394 comme résultat !...
# lsmod | grep 1394
ohci1394 24944 0
ieee1394 75800 2 sbp2,ohci1394
Qu'en penser ?
qu'une cause possible vient d'être éliminée :)
Mais, j'ai encore une carte contrôleur SCSI qui "traîne" dans mon
ordi... Devrais-je l'enlever pour voir si il se "passe qqch de mieux" ?
non, puisque le module qui pouvait amener le PB n'est pas chargé.
à mon avis, on commence à s'éparpiller: il faut donc reprendre le PB à zéro:
* virer/désactiver *tous* les daemons||pgms susceptibles d'interragir,
* lancer le client manuellement pour voir si l'exécution est correcte
de bout en bout (sans oublier de virer /var/lib/dhcp3/dhclient.leases
de façon à n'avoir aucun failover.)
Une fois que cette simple manip fonctionne correctement, on peut envisager
de rajouter une pièce par une pièce, en re-vérifiant le bon fonctionnement à
chaque étape.
Tu commencer aussi par faire un 1er test en enlevant la carte USB/FW, histoire
de voir si ça passe.
Egalement: cat /proc/interrupts pour voir sur quelles IRQs sont affectées les
cartes ETH & USB/FW, et éventuellement les inverser physiquement pour voir si
le schmilblick est-il vert (si c'est du PCI, les IRQs sont normalement affectées
en ordre croissant dans le sens slot AGP vers dernier PCI; pour Xpress,
je ne sais pas.)
JY
--
X-rated movies are all alike ... the only thing they leave to the
imagination is the plot.
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists Vous pouvez aussi ajouter le mot
``spam'' dans vos champs "From" et "Reply-To:"
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
---> Malheureusement lsmod ne donne aucun eth1394 comme résultat !... # lsmod | grep 1394 ohci1394 24944 0 ieee1394 75800 2 sbp2,ohci1394
Qu'en penser ?
qu'une cause possible vient d'être éliminée :)
Mais, j'ai encore une carte contrôleur SCSI qui "traîne" dans mon ordi... Devrais-je l'enlever pour voir si il se "passe qqch de mieux" ?
non, puisque le module qui pouvait amener le PB n'est pas chargé.
à mon avis, on commence à s'éparpiller: il faut donc reprendre le PB à zéro: * virer/désactiver *tous* les daemons||pgms susceptibles d'interragir, * lancer le client manuellement pour voir si l'exécution est correcte de bout en bout (sans oublier de virer /var/lib/dhcp3/dhclient.leases de façon à n'avoir aucun failover.)
Une fois que cette simple manip fonctionne correctement, on peut envisager de rajouter une pièce par une pièce, en re-vérifiant le bon fonctionnement à chaque étape.
Tu commencer aussi par faire un 1er test en enlevant la carte USB/FW, histoire de voir si ça passe.
Egalement: cat /proc/interrupts pour voir sur quelles IRQs sont affectées les cartes ETH & USB/FW, et éventuellement les inverser physiquement pour voir si le schmilblick est-il vert (si c'est du PCI, les IRQs sont normalement affectées en ordre croissant dans le sens slot AGP vers dernier PCI; pour Xpress, je ne sais pas.)
JY -- X-rated movies are all alike ... the only thing they leave to the imagination is the plot.
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers En cas de soucis, contactez EN ANGLAIS
hervé desrues
LM--- a écrit :
Bonsoir Jean-Yves, Re-Bonsoir à toutes et à tous,
L'une des 2 (eth0) était générée par le module 'eth1394' qui permet IP over 1394 (mais, comme le dit la doc, n'émule pas Ethernet), ce qui fait que c'est la carte SCSI qui préemptait sur DHCP puisque son module était chargé avant le module de la carte Ethernet.
Si c'est cela, ça peut de régler de plusieurs manières, par ordre de préf perso: * recompiler un kernel sans le module 'eth1394', * débarquer le module 'eth1394' par un script exécuté avant le dhcp-client, ou si impossible, exécuté en dernier et relançant le dhcp-client après coup, * bidouiller avec HAL pour qu'il inverse l'ordre des modules.
Quel est le contenu de ton /etc/udev/rules.d/70-persistent-net.rules ? A tout hasard si ça n'a pas déjà été évoqué...
rvdru
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers En cas de soucis, contactez EN ANGLAIS
LM--- a écrit :
Bonsoir Jean-Yves, Re-Bonsoir à toutes et à tous,
L'une des 2 (eth0) était générée par le module 'eth1394' qui permet IP
over 1394 (mais, comme le dit la doc, n'émule pas Ethernet), ce qui
fait que c'est la carte SCSI qui préemptait sur DHCP puisque son module
était chargé avant le module de la carte Ethernet.
Si c'est cela, ça peut de régler de plusieurs manières, par ordre de préf perso:
* recompiler un kernel sans le module 'eth1394',
* débarquer le module 'eth1394' par un script exécuté avant le dhcp-client,
ou si impossible, exécuté en dernier et relançant le dhcp-client après coup,
* bidouiller avec HAL pour qu'il inverse l'ordre des modules.
Quel est le contenu de ton /etc/udev/rules.d/70-persistent-net.rules ?
A tout hasard si ça n'a pas déjà été évoqué...
rvdru
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists Vous pouvez aussi ajouter le mot
``spam'' dans vos champs "From" et "Reply-To:"
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
L'une des 2 (eth0) était générée par le module 'eth1394' qui permet IP over 1394 (mais, comme le dit la doc, n'émule pas Ethernet), ce qui fait que c'est la carte SCSI qui préemptait sur DHCP puisque son module était chargé avant le module de la carte Ethernet.
Si c'est cela, ça peut de régler de plusieurs manières, par ordre de préf perso: * recompiler un kernel sans le module 'eth1394', * débarquer le module 'eth1394' par un script exécuté avant le dhcp-client, ou si impossible, exécuté en dernier et relançant le dhcp-client après coup, * bidouiller avec HAL pour qu'il inverse l'ordre des modules.
Quel est le contenu de ton /etc/udev/rules.d/70-persistent-net.rules ? A tout hasard si ça n'a pas déjà été évoqué...
rvdru
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers En cas de soucis, contactez EN ANGLAIS