4. Wer ist schuld dran?

Wer ist schuld dran?

  • S

    Hi

    ich installiere gerade Slackware 13.0 (linux 2.6.29.6-smp) auf einen Rechner mit zwei Realtek Karten

    01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 02)
02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 02)

    Ich hab folgendes Problem: wenn der Rechner ausgeschaltet ist und ich boote, dann wird der r8169 Modul geladen und die Netzwerkkarten funktionieren. Mach ich jedoch ein warmen restart (z.b. reboot eingeben), dann wird der Modul wieder geladen, aber ifconfig -a zeigt weder eth0 noch eth1. Auch die Einträge unter /sys/class/net sind nicht da oder nur ein Device vom beiden. Wenn ich dann den Rechner ausschalte und vom Stromnetz wegnehme, dann funktioniert alles wieder.

    Beim ersten Start bekomme ich

    r8169 0000:02:00.0: PCI INT A disabled
r8169 0000:01:00.0: PCI INT A disabled
r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded
r8169 0000:01:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
r8169 0000:01:00.0: setting latency timer to 64
r8169 0000:01:00.0: irq 26 for MSI/MSI-X
eth0: RTL8168c/8111c at 0xf8d40000, 00:90:0b:19:16:b4, XID 3c4000c0 IRQ 26
r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded
r8169 0000:02:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
r8169 0000:02:00.0: setting latency timer to 64
r8169 0000:02:00.0: irq 27 for MSI/MSI-X
eth1: RTL8168c/8111c at 0xf84e0000, 00:90:0b:19:16:b5, XID 3c4000c0 IRQ 27
r8169: eth0: link down
r8169: eth0: link down
ADDRCONF(NETDEV_UP): eth0: link is not ready
r8169: eth0: link up
ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
eth0: no IPv6 routers present

    Wenn ich aber einen Reboot mache, bekomme ich

    r8169 0000:02:00.0: PCI INT A disabled
r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded
r8169 0000:01:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
r8169 0000:01:00.0: cache line size of 32 is not supported
r8169 0000:01:00.0: PCI INT A disabled
r8169: probe of 0000:01:00.0 failed with error -22
....

    Da die Devices automatisch geschlossen werden, sobald der Treiber geladen ist, habe ich ausgeführt:

    $ lspci -v
....
01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev ff) (prog-if ff)
	!!! Unknown header type 7f
	Kernel modules: r8169
...

    und bei einem funktionieren Device sollte stehen:

    Subsystem: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller
	Flags: bus master, fast devsel, latency 0, IRQ 26
	I/O ports at ec00 [size=256]
	Memory at febff000 (64-bit, non-prefetchable) [size=4K]
	Memory at fdff0000 (64-bit, prefetchable) [size=64K]
	Expansion ROM at febc0000 [disabled] [size=128K]
	Capabilities: [40] Power Management version 3
	Capabilities: [50] MSI: Enable+ Count=1/1 Maskable- 64bit+
	Capabilities: [70] Express Endpoint, MSI 01
	Capabilities: [b0] MSI-X: Enable- Count=2 Masked-
	Capabilities: [d0] Vital Product Data
	Capabilities: [100] Advanced Error Reporting
	Capabilities: [140] Virtual Channel <?>
	Capabilities: [160] Device Serial Number 26-00-00-00-68-4c-e0-00
	Kernel driver in use: r8169
	Kernel modules: r8169

    häää??? Was ist denn da los? Ist das ein Treiber Problem, welches beim Runterfahren die Register der Karte komplett falsch schreibt und diese auch "kaputt" macht? Oder ist das Mainboard Gaga und hab nur Glück, dass beim ersten Start alles funktioniert?

    Ich weiß nicht, wie ich das Problem lösen könnte. Hat jemand ähnliche Erfahrungen schon gehabt?

    0
  • A

    supertux schrieb:

    Ich weiß nicht, wie ich das Problem lösen könnte.

    Man könnte jetzt versuchen, den aktuellsten Kernel hier http://www.kernel.org/ herunterzuladen, auf deinem System mit deiner Kernel-config konfigurieren und bauen und überprüfen, ob das Problem damit auftritt oder nicht. Vielleicht tritt es mit dem neuen Kernel nicht mehr auf.
    Man könnte noch versuchen (ob mit dem neuen oder mit deinem äleren Kernel), den r8169 Treiber nicht als Modul, sondern fest in den Kernel zu kompilieren - vielleicht ist es ein "Timing"-Problem...
    Interessant wäre noch die Ausgabe von dmesg o.ä. Vielleicht steht da mehr, weil diese Fehlermeldung

    supertux schrieb:

    r8169: probe of 0000:01:00.0 failed with error -22

    aus drivers/base/dd.c kommt und bedeutet, "die probe-Funktion des Treibers r8169 hat -EINVAL zurückgegeben" und EINVAL bedeutet einfach "Invalid argument". Die probe-Funktion des Treibers ist rtl8169_init_one() und dort ist unklar, wo -EINVAL zurückgegeben werden könnte...

    Viel Glück...

    0
  • L

    Ich habe zuhause fünf dieser Karten rumliegen, die ich von einem Techniker einer größeren Firma geschenkt bekommen habe. Die wurden ausgemustert, weil es durchgängig Probleme gab, zwei davon je Rechner zuverlässig zu betreiben, und das Problem softwaretechnisch nicht gelöst werden konnte.

    Nur als Hinweis, da ich leider keine Online-Quelle für dieses Problem liefern kann.

    0
  • P

    Richtig helfen kann ich auch nicht, aber es dürfte mit Deiner Linux- Distri zu tun haben. In meinem Uralt- Server (zuerst CentOS 4.2, zuletzt upgegraded auf CentOS 4.4) tun zwei 8169er klaglos ihren Dienst).

    0
Anmelden zum Antworten