suite à un apt-get update + upgrade (je suis sur Sarge), il y a apparemment un problème avec la façon dont discover gère les modules de mes deux cartes réseau :
en eth0 j'ai une realtek classique qui fonctionne très bien avec le module ne2k_pci
en eth1 j'ai une national semiconductor machintruc qui fonctionne très bien avec le module natsemi
tout ça avait été auto-détecté lors de mon passage de stable à sarge et fonctionnait à merveille jusqu'à une mise à jour récente dont discover faisait partie il me semble.
Sur eth0 j'avais mon routeur (serveur dhcp), lui même connecté à mon modem adsl (idem), tout était pour le mieux dans le meilleur des mondes possibles et rien de branché sur eth1.
Depuis la mise à jour, j'ai ça dans dmesg :
natsemi dp8381x driver, version 1.07+LK1.0.17, Sep 27, 2002
originally by Donald Becker <becker@scyld.com>
http://www.scyld.com/network/natsemi.html
2.4.x kernel port by Jeff Garzik, Tjeerd Mulder
PCI: Found IRQ 15 for device 0000:00:0f.0
eth0: NatSemi DP8381[56] at 0xe0c47000, 00:50:fc:70:ce:f8, IRQ 15.
puis un peu plus loin
PCI: Found IRQ 11 for device 0000:00:0c.0
PCI: Sharing IRQ 11 with 0000:00:0e.0
PCI: Sharing IRQ 11 with 0000:01:00.0
ne2k-pci.c:v1.03 9/22/2003 D. Becker/P. Gortmaker
http://www.scyld.com/network/ne2k-pci.html
PCI: Found IRQ 11 for device 0000:00:0e.0
PCI: Sharing IRQ 11 with 0000:00:0c.0
PCI: Sharing IRQ 11 with 0000:01:00.0
eth1: RealTek RTL-8029 found at 0x14a0, IRQ 11, 00:40:05:5A:CE:F2.
eth0: autonegotiation did not complete in 4000 usec.
Bref, ce pingouin neurasthénique se mélange complètement les pinceaux et me charge le module natsemi pour la carte realtek et le module ne2k_pci pour la carte national semiconductor, forcément, ça a du mal à fonctionner.
Un rmmod sur les deux modules puis un modprobe ne2k_pci suivi d'un modprobe natsemi (dans cet ordre) suffit à lui recaler les neurones en face des trous.
Mais faire ça à chaque démarrage me lasse quelque peu et tant qu'à faire si je peux aider à trouver une solution définitive pour tous ceux qui ont la même configuration que moi en aidant les développeurs debian à corriger ce "bug" je me dis que ça vaut le coup d'essayer.
Problème : je ne sais pas quelle est la cause de la défaillance décrite ici ? Qu'est ce qui controlle l'ordre dans lequel les modules sont installés (le problème vient il déjà de ça ?) ? Est-ce un bug du module natsemi qui ne devrait pas prendre une realtek pour une national semiconductor ? Est-ce que ça vient de discover ? etc...
Bref si quelqu'un pouvait me lancer des pistes de recherche et me donner quelques conseils pour traquer la bête fauve qui rode dans la distrib. debian, je lui serais assez reconnaissant :)
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
Corsinux
Laurent Giroud a écrit :
Hello,
Bonsoir,
suite à un apt-get update + upgrade (je suis sur Sarge), il y a apparemment un problème avec la façon dont discover gère les modules de mes deux cartes réseau :
en eth0 j'ai une realtek classique qui fonctionne très bien avec le module ne2k_pci en eth1 j'ai une national semiconductor machintruc qui fonctionne très bien avec le module natsemi
tout ça avait été auto-détecté lors de mon passage de stable à sarge et fonctionnait à merveille jusqu'à une mise à jour récente dont discover faisait partie il me semble.
Sur eth0 j'avais mon routeur (serveur dhcp), lui même connecté à mon modem adsl (idem), tout était pour le mieux dans le meilleur des mondes possibles et rien de branché sur eth1.
Depuis la mise à jour, j'ai ça dans dmesg :
natsemi dp8381x driver, version 1.07+LK1.0.17, Sep 27, 2002 originally by Donald Becker http://www.scyld.com/network/natsemi.html 2.4.x kernel port by Jeff Garzik, Tjeerd Mulder PCI: Found IRQ 15 for device 0000:00:0f.0 eth0: NatSemi DP8381[56] at 0xe0c47000, 00:50:fc:70:ce:f8, IRQ 15.
puis un peu plus loin
PCI: Found IRQ 11 for device 0000:00:0c.0 PCI: Sharing IRQ 11 with 0000:00:0e.0 PCI: Sharing IRQ 11 with 0000:01:00.0 ne2k-pci.c:v1.03 9/22/2003 D. Becker/P. Gortmaker http://www.scyld.com/network/ne2k-pci.html PCI: Found IRQ 11 for device 0000:00:0e.0 PCI: Sharing IRQ 11 with 0000:00:0c.0 PCI: Sharing IRQ 11 with 0000:01:00.0 eth1: RealTek RTL-8029 found at 0x14a0, IRQ 11, 00:40:05:5A:CE:F2. eth0: autonegotiation did not complete in 4000 usec.
Bref, ce pingouin neurasthénique se mélange complètement les pinceaux et me charge le module natsemi pour la carte realtek et le module ne2k_pci pour la carte national semiconductor, forcément, ça a du mal à fonctionner.
Un rmmod sur les deux modules puis un modprobe ne2k_pci suivi d'un modprobe natsemi (dans cet ordre) suffit à lui recaler les neurones en face des trous.
Mais faire ça à chaque démarrage me lasse quelque peu et tant qu'à faire si je peux aider à trouver une solution définitive pour tous ceux qui ont la même configuration
Il y a peut-être une solution : essaye de créer un fichier /etc/modutils/reseau (par exemple) qui contienne cela : alias eth0 ne2k_pci alias eth1 via-rhine
Ensuite : #update-modules en tant que root. Ca ne va pas corriger ce "bug", mais tu ne devrais plus avoir besoin de recharger les modules à la main. :)
que moi en aidant les développeurs debian à corriger ce "bug" je me dis que ça vaut le coup d'essayer. Problème : je ne sais pas quelle est la cause de la défaillance décrite ici ? Qu'est ce qui controlle l'ordre dans lequel les modules sont installés (le problème vient il déjà de ça ?) ? Est-ce un bug du module natsemi qui ne devrait pas prendre une realtek pour une national semiconductor ? Est-ce que ça vient de discover ? etc... Bref si quelqu'un pouvait me lancer des pistes de recherche et me donner quelques conseils pour traquer la bête fauve qui rode dans la distrib. debian, je lui serais assez reconnaissant :)
Merci d'avance.
Je t'en prie
Laurent
Anton'Santu
-- Pour finir, dit-il, je voudrais vous faire une ANNONCE. (Il prononça ce dernier mot avec tant de force et de soudaineté que tous ceux qui le pouvaient encore se redressèrent.) J'ai le regret de vous annoncer - quoique, je vous l'ai dit, undécante-un ans soit un temps bien insuffisant à passer parmi vous - que ceci est la FIN. Je m'en vais. Je pars MAINTENANT. ADIEU! -- J.R.R. Tolkien, "La Communauté de l'Anneau"
-- Pensez
Laurent Giroud a écrit :
Hello,
Bonsoir,
suite à un apt-get update + upgrade (je suis sur Sarge), il y a apparemment un problème avec la façon dont discover gère les modules de mes deux cartes réseau :
en eth0 j'ai une realtek classique qui fonctionne très bien avec le module ne2k_pci
en eth1 j'ai une national semiconductor machintruc qui fonctionne très bien avec le module natsemi
tout ça avait été auto-détecté lors de mon passage de stable à sarge et fonctionnait à merveille jusqu'à une mise à jour récente dont discover faisait partie il me semble.
Sur eth0 j'avais mon routeur (serveur dhcp), lui même connecté à mon modem adsl (idem), tout était pour le mieux dans le meilleur des mondes possibles et rien de branché sur eth1.
Depuis la mise à jour, j'ai ça dans dmesg :
natsemi dp8381x driver, version 1.07+LK1.0.17, Sep 27, 2002
originally by Donald Becker <becker@scyld.com>
http://www.scyld.com/network/natsemi.html
2.4.x kernel port by Jeff Garzik, Tjeerd Mulder
PCI: Found IRQ 15 for device 0000:00:0f.0
eth0: NatSemi DP8381[56] at 0xe0c47000, 00:50:fc:70:ce:f8, IRQ 15.
puis un peu plus loin
PCI: Found IRQ 11 for device 0000:00:0c.0
PCI: Sharing IRQ 11 with 0000:00:0e.0
PCI: Sharing IRQ 11 with 0000:01:00.0
ne2k-pci.c:v1.03 9/22/2003 D. Becker/P. Gortmaker
http://www.scyld.com/network/ne2k-pci.html
PCI: Found IRQ 11 for device 0000:00:0e.0
PCI: Sharing IRQ 11 with 0000:00:0c.0
PCI: Sharing IRQ 11 with 0000:01:00.0
eth1: RealTek RTL-8029 found at 0x14a0, IRQ 11, 00:40:05:5A:CE:F2.
eth0: autonegotiation did not complete in 4000 usec.
Bref, ce pingouin neurasthénique se mélange complètement les pinceaux et me charge le module natsemi pour la carte realtek et le module ne2k_pci pour la carte national semiconductor, forcément, ça a du mal à fonctionner.
Un rmmod sur les deux modules puis un modprobe ne2k_pci suivi d'un modprobe natsemi (dans cet ordre) suffit à lui recaler les neurones en face des trous.
Mais faire ça à chaque démarrage me lasse quelque peu et tant qu'à faire si je peux aider à trouver une solution définitive pour tous ceux qui ont la même configuration
Il y a peut-être une solution : essaye de créer un fichier
/etc/modutils/reseau (par exemple) qui contienne cela :
alias eth0 ne2k_pci
alias eth1 via-rhine
Ensuite : #update-modules en tant que root.
Ca ne va pas corriger ce "bug", mais tu ne devrais plus avoir besoin de
recharger les modules à la main. :)
que moi en aidant les développeurs debian à corriger ce "bug" je me dis que ça vaut le coup d'essayer.
Problème : je ne sais pas quelle est la cause de la défaillance décrite ici ? Qu'est ce qui controlle l'ordre dans lequel les modules sont installés (le problème vient il déjà de ça ?) ? Est-ce un bug du module natsemi qui ne devrait pas prendre une realtek pour une national semiconductor ? Est-ce que ça vient de discover ? etc...
Bref si quelqu'un pouvait me lancer des pistes de recherche et me donner quelques conseils pour traquer la bête fauve qui rode dans la distrib. debian, je lui serais assez reconnaissant :)
Merci d'avance.
Je t'en prie
Laurent
Anton'Santu
--
Pour finir, dit-il, je voudrais vous faire une ANNONCE. (Il prononça
ce dernier mot avec tant de force et de soudaineté que tous ceux qui
le pouvaient encore se redressèrent.) J'ai le regret de vous annoncer
- quoique, je vous l'ai dit, undécante-un ans soit un temps bien
insuffisant à passer parmi vous - que ceci est la FIN.
Je m'en vais. Je pars MAINTENANT. ADIEU!
-- J.R.R. Tolkien, "La Communauté de l'Anneau"
suite à un apt-get update + upgrade (je suis sur Sarge), il y a apparemment un problème avec la façon dont discover gère les modules de mes deux cartes réseau :
en eth0 j'ai une realtek classique qui fonctionne très bien avec le module ne2k_pci en eth1 j'ai une national semiconductor machintruc qui fonctionne très bien avec le module natsemi
tout ça avait été auto-détecté lors de mon passage de stable à sarge et fonctionnait à merveille jusqu'à une mise à jour récente dont discover faisait partie il me semble.
Sur eth0 j'avais mon routeur (serveur dhcp), lui même connecté à mon modem adsl (idem), tout était pour le mieux dans le meilleur des mondes possibles et rien de branché sur eth1.
Depuis la mise à jour, j'ai ça dans dmesg :
natsemi dp8381x driver, version 1.07+LK1.0.17, Sep 27, 2002 originally by Donald Becker http://www.scyld.com/network/natsemi.html 2.4.x kernel port by Jeff Garzik, Tjeerd Mulder PCI: Found IRQ 15 for device 0000:00:0f.0 eth0: NatSemi DP8381[56] at 0xe0c47000, 00:50:fc:70:ce:f8, IRQ 15.
puis un peu plus loin
PCI: Found IRQ 11 for device 0000:00:0c.0 PCI: Sharing IRQ 11 with 0000:00:0e.0 PCI: Sharing IRQ 11 with 0000:01:00.0 ne2k-pci.c:v1.03 9/22/2003 D. Becker/P. Gortmaker http://www.scyld.com/network/ne2k-pci.html PCI: Found IRQ 11 for device 0000:00:0e.0 PCI: Sharing IRQ 11 with 0000:00:0c.0 PCI: Sharing IRQ 11 with 0000:01:00.0 eth1: RealTek RTL-8029 found at 0x14a0, IRQ 11, 00:40:05:5A:CE:F2. eth0: autonegotiation did not complete in 4000 usec.
Bref, ce pingouin neurasthénique se mélange complètement les pinceaux et me charge le module natsemi pour la carte realtek et le module ne2k_pci pour la carte national semiconductor, forcément, ça a du mal à fonctionner.
Un rmmod sur les deux modules puis un modprobe ne2k_pci suivi d'un modprobe natsemi (dans cet ordre) suffit à lui recaler les neurones en face des trous.
Mais faire ça à chaque démarrage me lasse quelque peu et tant qu'à faire si je peux aider à trouver une solution définitive pour tous ceux qui ont la même configuration
Il y a peut-être une solution : essaye de créer un fichier /etc/modutils/reseau (par exemple) qui contienne cela : alias eth0 ne2k_pci alias eth1 via-rhine
Ensuite : #update-modules en tant que root. Ca ne va pas corriger ce "bug", mais tu ne devrais plus avoir besoin de recharger les modules à la main. :)
que moi en aidant les développeurs debian à corriger ce "bug" je me dis que ça vaut le coup d'essayer. Problème : je ne sais pas quelle est la cause de la défaillance décrite ici ? Qu'est ce qui controlle l'ordre dans lequel les modules sont installés (le problème vient il déjà de ça ?) ? Est-ce un bug du module natsemi qui ne devrait pas prendre une realtek pour une national semiconductor ? Est-ce que ça vient de discover ? etc... Bref si quelqu'un pouvait me lancer des pistes de recherche et me donner quelques conseils pour traquer la bête fauve qui rode dans la distrib. debian, je lui serais assez reconnaissant :)
Merci d'avance.
Je t'en prie
Laurent
Anton'Santu
-- Pour finir, dit-il, je voudrais vous faire une ANNONCE. (Il prononça ce dernier mot avec tant de force et de soudaineté que tous ceux qui le pouvaient encore se redressèrent.) J'ai le regret de vous annoncer - quoique, je vous l'ai dit, undécante-un ans soit un temps bien insuffisant à passer parmi vous - que ceci est la FIN. Je m'en vais. Je pars MAINTENANT. ADIEU! -- J.R.R. Tolkien, "La Communauté de l'Anneau"
