Mise à jour pilote Ethernet - comment faire proprement?

Bonjour,
J’ai eu des problèmes avec mon port Ethernet (composant de la carte mère).
La communication ne voulait pas toujours s’établir.
En faisant au boot un “ifconfig” j’ai constaté qu’il y avait des milliards de paquets perdus (dropped packets)
J’ai trouvé ça étrange, et mes recherches sur Google n’ont pas donné de résultat bien clair.

Pour isoler le problème, j’ai commencé par vérifier les câbles, et le routeur.
Comme tout allait bien de ce côté, j’ai attrapé une vielle carte Ethernet PCI, et j’ai branché mon câble réseau dessus.
Voici ce que ça donnait:

$ sudo ifconfig
eth0 Link encap:Ethernet HWaddr 00:19:66:a9:81:c0
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:7958411121 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
Interruption:250 Adresse de base:0xe000

eth1 Link encap:Ethernet HWaddr 00:50:ba:28:0e:e5
inet adr:192.168.0.101 Bcast:192.168.0.255 Masque:255.255.255.0
adr inet6: fe80::250:baff:fe28:ee5/64 Scope:Lien
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:113 errors:0 dropped:0 overruns:0 frame:0
TX packets:64 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:1000
RX bytes:35872 (35.0 KiB) TX bytes:9719 (9.4 KiB)
Interruption:22 Adresse de base:0xb800

lo Link encap:Boucle locale
inet adr:127.0.0.1 Masque:255.0.0.0
adr inet6: ::1/128 Scope:Hôte
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:8 errors:0 dropped:0 overruns:0 frame:0
TX packets:8 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:0
RX bytes:560 (560.0 B) TX bytes:560 (560.0 B)

Et une seconde fois aussitôt après:

$ sudo ifconfig
eth0 Link encap:Ethernet HWaddr 00:19:66:a9:81:c0
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:11797796944 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
Interruption:250 Adresse de base:0xe000

eth1 Link encap:Ethernet HWaddr 00:50:ba:28:0e:e5
inet adr:192.168.0.101 Bcast:192.168.0.255 Masque:255.255.255.0
adr inet6: fe80::250:baff:fe28:ee5/64 Scope:Lien
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:126 errors:0 dropped:0 overruns:0 frame:0
TX packets:64 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:1000
RX bytes:40178 (39.2 KiB) TX bytes:9719 (9.4 KiB)
Interruption:22 Adresse de base:0xb800

lo Link encap:Boucle locale
inet adr:127.0.0.1 Masque:255.0.0.0
adr inet6: ::1/128 Scope:Hôte
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:8 errors:0 dropped:0 overruns:0 frame:0
TX packets:8 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:0
RX bytes:560 (560.0 B) TX bytes:560 (560.0 B)

On constate que bien qu’aucun câble ne soit branché dans la fiche Ethernet sur la carte mère, le compteur des paquets perdus continue à tourner comme un fou.

J’ai donc désactivé ce port dans le bios pour le moment.

Maintenant en allant faire un lspci -vv, voici ce que ça donne pour la carte intégrée à la carte mère:

02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 02)
Subsystem: ASRock Incorporation Device 8168
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 32 bytes
Interrupt: pin A routed to IRQ 1274
Region 0: I/O ports at c800 [size=256]
Region 2: Memory at cffff000 (64-bit, prefetchable) [size=4K]
Region 4: Memory at cffe0000 (64-bit, prefetchable) [size=64K]
Expansion ROM at f96f0000 [disabled] [size=64K]
Capabilities: [40] Power Management version 3
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [50] Message Signalled Interrupts: Mask- 64bit+ Queue=0/1 Enable+
Address: 00000000fee0300c Data: 41a1
Capabilities: [70] Express (v1) Endpoint, MSI 01
DevCap: MaxPayload 256 bytes, PhantFunc 0, Latency L0s <512ns, L1 <8us
ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop-
MaxPayload 128 bytes, MaxReadReq 512 bytes
DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq+ AuxPwr+ TransPend-
LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Latency L0 <512ns, L1 <64us
ClockPM+ Suprise- LLActRep- BwNot-
LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk-
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
Capabilities: [b0] MSI-X: Enable- Mask- TabSize=2
Vector table: BAR=4 offset=00000000
PBA: BAR=4 offset=00000800
Capabilities: [d0] Vital Product Data <?>
Capabilities: [100] Advanced Error Reporting <?>
Capabilities: [140] Virtual Channel <?>
Capabilities: [160] Device Serial Number 00-e0-4c-68-12-34-56-78
Kernel driver in use: r8169
kernel modules: r8169

Il me semble que le pilote utilisé par le noyau n’est pas celui qu’il faudrait.

En allant sur le site de Realtek, j’ai trouvé un pilote récent qui correspondrait bien au matériel de ma carte mère.

Ma question est donc:

Comment placer ce pilote pour qu’il soit appelé au boot?
Si je me fie à ce que lspci donne comme information, c’est un module du noyau.
Faut-il recompiler le noyau?

Merci de votre avis.
JP

En fait, je ne l’avais pas vu, mais il y a un fichier README qui accompagne le pilote…
Donc on peut considérer que c’est résolu.
Merci
JP

Attention!
La procédure décrite par Realtek est correcte, mais…Il manque une chose importante.
En effet, au reboot suivant le mauvais pilote est de retour :imp:
Pour éviter ça il faut
1.- Le mettre en blacklist
2.- Faire un update-initramfs -u (lu quelque part)
3.- Ajouter au fichier /etc/network/interfaces
la ligne:
pre-up modprobe r8168

(si c’est bien le nouveau pilote)

En espérant avoir aidé quelqu’un
JP

Juste pour info, le module du noyau standard qui gère la famille des contrôleurs gigabit ethernet Realtek (RTL 8169, 8168, 8111…) est bien r8169. Autrement il n’aurait pas été chargé. Mais il peut y avoir des bugs en fonction de la version du noyau et de la variante du contrôleur, il suffit de regarder dans les changelogs du noyau concernant ce module.