Problème récalcitrant avec mon Interface Ethernet :-(
4 réponses
Lucien K.
Bonjour,
Comme je l'ai exposé dans maints appels à l'aide, j'ai un dûr-à-cuire de
problème avec mon interface ethernet.
J'ai une Debian Woody 3.0r1 kernel 2.2.20
Mon "/proc/pci" me dit :
{
Bus 0, device 12, function 0:
Ethernet controller: VIA Technologies Unknown device (rev 67).
Vendor id=1106. Device id=3065.
Medium devsel. IRQ 11. Master Capable. Latency=32. Min Gnt=139.Max
Lat=109.
I/O at 0xe800 [0xe801].
Non-prefetchable 32 bit memory at 0xd9000000 [0xd9000000].
}
Et mon "/var/log/syslog" me dit :
{
Jan 7 11:32:36 (null) kernel: via-rhine.c:v1.08b-LK1.0.1 12/14/2000
Written by Donald Becker
Jan 7 11:32:36 (null) kernel: http://www.scyld.com/network/via-rhine.html
Jan 7 11:32:36 (null) kernel: eth0: VIA VT6102 Rhine-II at 0xe800,
00:00:00:00:00:00, IRQ 11.
}
... et cette adresse physique égale à 00:00:00:00:00:00 me gène beaucoup !
Quelqu'un auraît une idée à propos de cette adresse complètement fantasque
???
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
JKB
Le 07-01-2004, à propos de Problème récalcitrant avec mon Interface Ethernet :-(, Lucien K. écrivait dans fr.comp.os.linux.configuration :
Bonjour,
Comme je l'ai exposé dans maints appels à l'aide, j'ai un dûr-à-cuire de problème avec mon interface ethernet.
J'ai une Debian Woody 3.0r1 kernel 2.2.20
Mon "/proc/pci" me dit : { Bus 0, device 12, function 0: Ethernet controller: VIA Technologies Unknown device (rev 67). Vendor id06. Device id065. Medium devsel. IRQ 11. Master Capable. Latency2. Min Gnt9.Max Lat9. I/O at 0xe800 [0xe801]. Non-prefetchable 32 bit memory at 0xd9000000 [0xd9000000]. }
Et mon "/var/log/syslog" me dit : { Jan 7 11:32:36 (null) kernel: via-rhine.c:v1.08b-LK1.0.1 12/14/2000 Written by Donald Becker Jan 7 11:32:36 (null) kernel: http://www.scyld.com/network/via-rhine.html Jan 7 11:32:36 (null) kernel: eth0: VIA VT6102 Rhine-II at 0xe800, 00:00:00:00:00:00, IRQ 11. }
... et cette adresse physique égale à 00:00:00:00:00:00 me gène beaucoup !
Quelqu'un auraît une idée à propos de cette adresse complètement fantasque ???
Je pense que le résultat doit être sympathique. J'ai déjà eu ce genre de chose avec une carte ethernet foutue. Sinon, il faudrait voir à jouer avec arp pour forcer une adresse ethernet à la carte.
Autre chose : j'ai eu un problème avec une hme de Sun sur une Ultra 1 et j'ai fait une recherche dans les news (solution, rajouter à la sauvage un usleep(1) dans les sources du pilote sunhme.c du noyau !) et je suis tombé par hasard sur un post donnant une solution à ce genre de problème (et avec ce composant). Par contre, comme je ne cherchais pas spécifiquement ce genre d'info, je n'ai pas gardé l'adresse.
Cordialement,
JKB
Le 07-01-2004, à propos de
Problème récalcitrant avec mon Interface Ethernet :-(,
Lucien K. écrivait dans fr.comp.os.linux.configuration :
Bonjour,
Comme je l'ai exposé dans maints appels à l'aide, j'ai un dûr-à-cuire de
problème avec mon interface ethernet.
J'ai une Debian Woody 3.0r1 kernel 2.2.20
Mon "/proc/pci" me dit :
{
Bus 0, device 12, function 0:
Ethernet controller: VIA Technologies Unknown device (rev 67).
Vendor id06. Device id065.
Medium devsel. IRQ 11. Master Capable. Latency2. Min Gnt9.Max
Lat9.
I/O at 0xe800 [0xe801].
Non-prefetchable 32 bit memory at 0xd9000000 [0xd9000000].
}
Et mon "/var/log/syslog" me dit :
{
Jan 7 11:32:36 (null) kernel: via-rhine.c:v1.08b-LK1.0.1 12/14/2000
Written by Donald Becker
Jan 7 11:32:36 (null) kernel: http://www.scyld.com/network/via-rhine.html
Jan 7 11:32:36 (null) kernel: eth0: VIA VT6102 Rhine-II at 0xe800,
00:00:00:00:00:00, IRQ 11.
}
... et cette adresse physique égale à 00:00:00:00:00:00 me gène beaucoup !
Quelqu'un auraît une idée à propos de cette adresse complètement fantasque
???
Je pense que le résultat doit être sympathique. J'ai déjà eu ce
genre de chose avec une carte ethernet foutue. Sinon, il faudrait
voir à jouer avec arp pour forcer une adresse ethernet à la carte.
Autre chose : j'ai eu un problème avec une hme de Sun sur une Ultra
1 et j'ai fait une recherche dans les news (solution, rajouter à la
sauvage un usleep(1) dans les sources du pilote sunhme.c du noyau !)
et je suis tombé par hasard sur un post donnant une solution à ce
genre de problème (et avec ce composant). Par contre, comme je ne
cherchais pas spécifiquement ce genre d'info, je n'ai pas gardé
l'adresse.
Le 07-01-2004, à propos de Problème récalcitrant avec mon Interface Ethernet :-(, Lucien K. écrivait dans fr.comp.os.linux.configuration :
Bonjour,
Comme je l'ai exposé dans maints appels à l'aide, j'ai un dûr-à-cuire de problème avec mon interface ethernet.
J'ai une Debian Woody 3.0r1 kernel 2.2.20
Mon "/proc/pci" me dit : { Bus 0, device 12, function 0: Ethernet controller: VIA Technologies Unknown device (rev 67). Vendor id06. Device id065. Medium devsel. IRQ 11. Master Capable. Latency2. Min Gnt9.Max Lat9. I/O at 0xe800 [0xe801]. Non-prefetchable 32 bit memory at 0xd9000000 [0xd9000000]. }
Et mon "/var/log/syslog" me dit : { Jan 7 11:32:36 (null) kernel: via-rhine.c:v1.08b-LK1.0.1 12/14/2000 Written by Donald Becker Jan 7 11:32:36 (null) kernel: http://www.scyld.com/network/via-rhine.html Jan 7 11:32:36 (null) kernel: eth0: VIA VT6102 Rhine-II at 0xe800, 00:00:00:00:00:00, IRQ 11. }
... et cette adresse physique égale à 00:00:00:00:00:00 me gène beaucoup !
Quelqu'un auraît une idée à propos de cette adresse complètement fantasque ???
Je pense que le résultat doit être sympathique. J'ai déjà eu ce genre de chose avec une carte ethernet foutue. Sinon, il faudrait voir à jouer avec arp pour forcer une adresse ethernet à la carte.
Autre chose : j'ai eu un problème avec une hme de Sun sur une Ultra 1 et j'ai fait une recherche dans les news (solution, rajouter à la sauvage un usleep(1) dans les sources du pilote sunhme.c du noyau !) et je suis tombé par hasard sur un post donnant une solution à ce genre de problème (et avec ce composant). Par contre, comme je ne cherchais pas spécifiquement ce genre d'info, je n'ai pas gardé l'adresse.
Cordialement,
JKB
Erwann ABALEA
On Wed, 7 Jan 2004, JKB wrote:
[...]
Autre chose : j'ai eu un problème avec une hme de Sun sur une Ultra 1 et j'ai fait une recherche dans les news (solution, rajouter à la sauvage un usleep(1) dans les sources du pilote sunhme.c du noyau !)
C'est une des solutions. L'autre solution soft, c'est de détecter le transmit timeout, et de resetter l'interface. La meilleure solution: installer une autre carte réseau (même une autre hme, le problème ne survient que sur l'interface intégrée). Dans mon cas, j'ai une quad. C'est le même driver (hme), mais je n'ai plus ce problème.
-- Erwann ABALEA - RSA PGP Key ID: 0x2D0EABD5 ----- Je tutoie par habitude. Ne te plains pas, en général, je ne vouvoie que ceux que je hais vicéralement. Je n'arrive pas à haïr une paramécie. -+- FJ in GNU - Le neuneu monocellulaire siscipare -+-
On Wed, 7 Jan 2004, JKB wrote:
[...]
Autre chose : j'ai eu un problème avec une hme de Sun sur une Ultra
1 et j'ai fait une recherche dans les news (solution, rajouter à la
sauvage un usleep(1) dans les sources du pilote sunhme.c du noyau !)
C'est une des solutions. L'autre solution soft, c'est de détecter le
transmit timeout, et de resetter l'interface.
La meilleure solution: installer une autre carte réseau (même une autre
hme, le problème ne survient que sur l'interface intégrée). Dans mon cas,
j'ai une quad. C'est le même driver (hme), mais je n'ai plus ce problème.
--
Erwann ABALEA <erwann@abalea.com> - RSA PGP Key ID: 0x2D0EABD5
-----
Je tutoie par habitude. Ne te plains pas, en général,
je ne vouvoie que ceux que je hais vicéralement.
Je n'arrive pas à haïr une paramécie.
-+- FJ in GNU - Le neuneu monocellulaire siscipare -+-
Autre chose : j'ai eu un problème avec une hme de Sun sur une Ultra 1 et j'ai fait une recherche dans les news (solution, rajouter à la sauvage un usleep(1) dans les sources du pilote sunhme.c du noyau !)
C'est une des solutions. L'autre solution soft, c'est de détecter le transmit timeout, et de resetter l'interface. La meilleure solution: installer une autre carte réseau (même une autre hme, le problème ne survient que sur l'interface intégrée). Dans mon cas, j'ai une quad. C'est le même driver (hme), mais je n'ai plus ce problème.
-- Erwann ABALEA - RSA PGP Key ID: 0x2D0EABD5 ----- Je tutoie par habitude. Ne te plains pas, en général, je ne vouvoie que ceux que je hais vicéralement. Je n'arrive pas à haïr une paramécie. -+- FJ in GNU - Le neuneu monocellulaire siscipare -+-
JKB
Le 07-01-2004, à propos de Re: Problème récalcitrant avec mon Interface Ethernet :-(, Erwann ABALEA écrivait dans fr.comp.os.linux.configuration :
On Wed, 7 Jan 2004, JKB wrote:
[...]
Autre chose : j'ai eu un problème avec une hme de Sun sur une Ultra 1 et j'ai fait une recherche dans les news (solution, rajouter à la sauvage un usleep(1) dans les sources du pilote sunhme.c du noyau !)
C'est une des solutions. L'autre solution soft, c'est de détecter le transmit timeout, et de resetter l'interface.
Oui, comment ? J'ai tout essayé en vain... La table arp est attaquée et attend désepérément une réponse qui n'arrive pas. On est dans un dead lock.
La meilleure solution: installer une autre carte réseau (même une autre hme, le problème ne survient que sur l'interface intégrée). Dans mon cas, j'ai une quad. C'est le même driver (hme), mais je n'ai plus ce problème.
Exact, que sur l'interface intégrée et cela dépend des appareils branchés derrière.
Cordialement,
JKB
Le 07-01-2004, à propos de
Re: Problème récalcitrant avec mon Interface Ethernet :-(,
Erwann ABALEA écrivait dans fr.comp.os.linux.configuration :
On Wed, 7 Jan 2004, JKB wrote:
[...]
Autre chose : j'ai eu un problème avec une hme de Sun sur une Ultra
1 et j'ai fait une recherche dans les news (solution, rajouter à la
sauvage un usleep(1) dans les sources du pilote sunhme.c du noyau !)
C'est une des solutions. L'autre solution soft, c'est de détecter le
transmit timeout, et de resetter l'interface.
Oui, comment ? J'ai tout essayé en vain... La table arp est attaquée
et attend désepérément une réponse qui n'arrive pas. On est dans un
dead lock.
La meilleure solution: installer une autre carte réseau (même une autre
hme, le problème ne survient que sur l'interface intégrée). Dans mon cas,
j'ai une quad. C'est le même driver (hme), mais je n'ai plus ce problème.
Exact, que sur l'interface intégrée et cela dépend des appareils
branchés derrière.
Le 07-01-2004, à propos de Re: Problème récalcitrant avec mon Interface Ethernet :-(, Erwann ABALEA écrivait dans fr.comp.os.linux.configuration :
On Wed, 7 Jan 2004, JKB wrote:
[...]
Autre chose : j'ai eu un problème avec une hme de Sun sur une Ultra 1 et j'ai fait une recherche dans les news (solution, rajouter à la sauvage un usleep(1) dans les sources du pilote sunhme.c du noyau !)
C'est une des solutions. L'autre solution soft, c'est de détecter le transmit timeout, et de resetter l'interface.
Oui, comment ? J'ai tout essayé en vain... La table arp est attaquée et attend désepérément une réponse qui n'arrive pas. On est dans un dead lock.
La meilleure solution: installer une autre carte réseau (même une autre hme, le problème ne survient que sur l'interface intégrée). Dans mon cas, j'ai une quad. C'est le même driver (hme), mais je n'ai plus ce problème.
Exact, que sur l'interface intégrée et cela dépend des appareils branchés derrière.
Cordialement,
JKB
Erwann ABALEA
On Wed, 7 Jan 2004, JKB wrote:
Le 07-01-2004, à propos de Re: Problème récalcitrant avec mon Interface Ethernet :-(, Erwann ABALEA écrivait dans fr.comp.os.linux.configuration :
On Wed, 7 Jan 2004, JKB wrote:
[...]
Autre chose : j'ai eu un problème avec une hme de Sun sur une Ultra 1 et j'ai fait une recherche dans les news (solution, rajouter à la sauvage un usleep(1) dans les sources du pilote sunhme.c du noyau !)
C'est une des solutions. L'autre solution soft, c'est de détecter le transmit timeout, et de resetter l'interface.
Oui, comment ? J'ai tout essayé en vain...
Je sais plus trop, je crois bien qu'il y a 2 patchs qui trainent. J'utilise la version avec le usleep(1) de toute façon. ;)
La table arp est attaquée et attend désepérément une réponse qui n'arrive pas. On est dans un dead lock.
Comment ça qui n'arrive pas? Il me semble que quand l'interface hme0 de l'Ultra1 déconne, elle peut toujours recevoir, mais plus émettre, non?
La meilleure solution: installer une autre carte réseau (même une autre hme, le problème ne survient que sur l'interface intégrée). Dans mon cas, j'ai une quad. C'est le même driver (hme), mais je n'ai plus ce problème.
Exact, que sur l'interface intégrée et cela dépend des appareils branchés derrière.
Ah? Je savais pas que ça dépendait de ça. Derrière ma hme0, j'avais un SpeedTouch Home, donc signalisation en 10Mbps, et j'étais (je suis toujours) en ADSL 512k. J'ai eu assez rarement le 'Transmit Timeout', mais je l'ai quand même eu.
-- Erwann ABALEA - RSA PGP Key ID: 0x2D0EABD5 ----- Tous cela, il faut que ça change. Je PAYE mon abonnement Internet et j'exige que mon vote et mes opinions soient pris en considération. -+- Rocou In GNU - Les payeurs ne sont pas les conseilleurs -+-
On Wed, 7 Jan 2004, JKB wrote:
Le 07-01-2004, à propos de
Re: Problème récalcitrant avec mon Interface Ethernet :-(,
Erwann ABALEA écrivait dans fr.comp.os.linux.configuration :
On Wed, 7 Jan 2004, JKB wrote:
[...]
Autre chose : j'ai eu un problème avec une hme de Sun sur une Ultra
1 et j'ai fait une recherche dans les news (solution, rajouter à la
sauvage un usleep(1) dans les sources du pilote sunhme.c du noyau !)
C'est une des solutions. L'autre solution soft, c'est de détecter le
transmit timeout, et de resetter l'interface.
Oui, comment ? J'ai tout essayé en vain...
Je sais plus trop, je crois bien qu'il y a 2 patchs qui trainent.
J'utilise la version avec le usleep(1) de toute façon. ;)
La table arp est attaquée
et attend désepérément une réponse qui n'arrive pas. On est dans un
dead lock.
Comment ça qui n'arrive pas? Il me semble que quand l'interface hme0 de
l'Ultra1 déconne, elle peut toujours recevoir, mais plus émettre, non?
La meilleure solution: installer une autre carte réseau (même une autre
hme, le problème ne survient que sur l'interface intégrée). Dans mon cas,
j'ai une quad. C'est le même driver (hme), mais je n'ai plus ce problème.
Exact, que sur l'interface intégrée et cela dépend des appareils
branchés derrière.
Ah? Je savais pas que ça dépendait de ça. Derrière ma hme0, j'avais un
SpeedTouch Home, donc signalisation en 10Mbps, et j'étais (je suis
toujours) en ADSL 512k. J'ai eu assez rarement le 'Transmit Timeout', mais
je l'ai quand même eu.
--
Erwann ABALEA <erwann@abalea.com> - RSA PGP Key ID: 0x2D0EABD5
-----
Tous cela, il faut que ça change. Je PAYE mon abonnement Internet et
j'exige que mon vote et mes opinions soient pris en considération.
-+- Rocou In GNU - Les payeurs ne sont pas les conseilleurs -+-
Le 07-01-2004, à propos de Re: Problème récalcitrant avec mon Interface Ethernet :-(, Erwann ABALEA écrivait dans fr.comp.os.linux.configuration :
On Wed, 7 Jan 2004, JKB wrote:
[...]
Autre chose : j'ai eu un problème avec une hme de Sun sur une Ultra 1 et j'ai fait une recherche dans les news (solution, rajouter à la sauvage un usleep(1) dans les sources du pilote sunhme.c du noyau !)
C'est une des solutions. L'autre solution soft, c'est de détecter le transmit timeout, et de resetter l'interface.
Oui, comment ? J'ai tout essayé en vain...
Je sais plus trop, je crois bien qu'il y a 2 patchs qui trainent. J'utilise la version avec le usleep(1) de toute façon. ;)
La table arp est attaquée et attend désepérément une réponse qui n'arrive pas. On est dans un dead lock.
Comment ça qui n'arrive pas? Il me semble que quand l'interface hme0 de l'Ultra1 déconne, elle peut toujours recevoir, mais plus émettre, non?
La meilleure solution: installer une autre carte réseau (même une autre hme, le problème ne survient que sur l'interface intégrée). Dans mon cas, j'ai une quad. C'est le même driver (hme), mais je n'ai plus ce problème.
Exact, que sur l'interface intégrée et cela dépend des appareils branchés derrière.
Ah? Je savais pas que ça dépendait de ça. Derrière ma hme0, j'avais un SpeedTouch Home, donc signalisation en 10Mbps, et j'étais (je suis toujours) en ADSL 512k. J'ai eu assez rarement le 'Transmit Timeout', mais je l'ai quand même eu.
-- Erwann ABALEA - RSA PGP Key ID: 0x2D0EABD5 ----- Tous cela, il faut que ça change. Je PAYE mon abonnement Internet et j'exige que mon vote et mes opinions soient pris en considération. -+- Rocou In GNU - Les payeurs ne sont pas les conseilleurs -+-
