[gelöst] mii-tool eth0 SIOCGMIIREG on eth0 failed: Input/out

[bullgard]

Hallo Forum,

[Wheezy]

Code: Alles auswählen

~$ sudo mii-tool eth0;
SIOCGMIIREG on eth0 failed: Input/output error;
SIOCGMIIREG on eth0 failed: Input/output error;
eth0: negotiated 100baseTx-FD flow-control, link ok

Diese Nachrichtenverbindung funktioniert. Warum erhalte ich dennoch diese doppelte Fehlermeldung? Sie tritt auch bei anderen Leuten auf: https://bugzilla.redhat.com/show_bug.cgi?id=491358

Mit freundlichen Grüßen
bullgard

[rendegast]

Der Bugreport bezieht sich auf e1000e.

Code: Alles auswählen

lspci -nnv | grep -i eth -A15

?

In dem speziellen Fall gibt es bei Intel außer dem im kernel (3.9) verwendeten Treiber 2.2.14
noch die 2.3.2 und 2.4.14,
die gerade bei diesen Stellen stark vom 2.2.14 abweichen.
Einfach das Makefile ausführen,
e1000e.ko nach zBsp. /lib/modules/$KERNEL/misc/$VER/ kopieren,
'depmod -a'
und 'update-iniramfs -u -kall'.
(Diese Stelle hat meiner Erfahrung nach den Vorteil,
daß beim depmod die neue Datei referenziert wird, ohne daß die alte speziell deaktiviert werden muß.)
Probe:

Code: Alles auswählen

modinfo e1000e | grep filename

zeigt den jeweilig aktiven Treiber.

Direkter Test durch Entladen/Laden per 'modprobe -vr ....' / 'modprobe -v ....'
(nur beim lokalen Rechner, bei einem Remote-Server wäre natürlich die Verbindung weg)




------------------------------------------------------
Anm.
die "vanilla"-Treiber 2.2.14 <-> 2.3.2 / 2.4.14 unterstützen verschiedene Kernelmodelle.
Für den backports-Kernel 3.9 kann ich nur 2.3.2 und 2.4.14 kompilieren.

Dagegen auf einem SLES mit Kernel 3.0 funktioniert das Bauen nur beim 2.2.14.
(Mit einem Hack zwar auch der 2.3.2, der Einsatz war mir auf dem Server dann aber "zu heiß")

[bullgard]

Hallo rendegast,

Der Bugreport bezieht sich auf e1000e.

Ja.

Code: Alles auswählen

lspci -nnv | grep -i eth -A15

?

Code: Alles auswählen

~$ lspci -nnv | grep -i eth -A15;
 Kernel driver in use: e1000e

In dem speziellen Fall gibt es bei Intel außer dem im kernel (3.9) verwendeten Treiber 2.2.14 noch die 2.3.2 und 2.4.14, die gerade bei diesen Stellen stark vom 2.2.14 abweichen.
Einfach das Makefile ausführen,
e1000e.ko nach zBsp. /lib/modules/$KERNEL/misc/$VER/ kopieren,
'depmod -a'
und 'update-iniramfs -u -kall'.
(Diese Stelle hat meiner Erfahrung nach den Vorteil, daß beim depmod die neue Datei referenziert wird, ohne daß die alte speziell deaktiviert werden muß.)
Probe:

Code: Alles auswählen

modinfo e1000e | grep filename

zeigt den jeweilig aktiven Treiber.
Direkter Test durch Entladen/Laden per 'modprobe -vr ....' / 'modprobe -v ....'
(nur beim lokalen Rechner, bei einem Remote-Server wäre natürlich die Verbindung weg)
-----------------------------------------------------
Anm. die "vanilla"-Treiber 2.2.14 <-> 2.3.2 / 2.4.14 unterstützen verschiedene Kernelmodelle.
Für den backports-Kernel 3.9 kann ich nur 2.3.2 und 2.2.14 kompilieren.
Dagegen auf einem SLES mit Kernel 3.0 funktioniert das Bauen nur beim 2.2.14.
(Mit einem Hack zwar auch der 2.3.2, der Einsatz war mir auf dem Server dann aber "zu heiß")

Deine Ausführungen zeigen mir, daß am Treiber e1000 enoch stark entwickelt wird. Ich werde ihn deshalb nicht selbst kompilieren. Ich habe Zeit zu warten, da ich den Fehler nun kenne.
Vielen Dank für Deine prima Hilfe!
bullgard

[rendegast]

... daß am Treiber e1000 enoch stark entwickelt wird.

Es ging um e1000e.

[bullgard]

... daß am Treiber e1000 enoch stark entwickelt wird.

Es ging um e1000e.

Ja. Mein Tippfehler.