# [gelöst] Kein Netzwerk auf AMD64+Intel PRO/1000, x86 klappt.

## sprittwicht

Einen wunderschönen...

Ich wollte meinen internen Mainboard-NIC durch einen "Intel PRO/1000 PT Desktop Adapter" ablösen.

Nun klappt dhcp nicht mehr.  :Sad: 

Ich boote den Kernel von Festplatte, das Root-Dateisystem kommt dann per nfsroot von einem nfs-Server. Leider hängt der Rechner nun beim Booten, egal ob die Onboard-Netzwerkkarte im Bios abgeschaltet ist oder weiter in Betrieb. Ich hab auch schon mit dem Kernelparameter "ip=...,eth0/eth1" rumgespielt, ohne Erfolg. Wenn ich die Logs richtig deute, kommen die dhcp-Anfragen noch nichtmal am Server an.

Am Server ist die neue Mac-Adresse der Intel-Karte eingerichtet. Ein auf dem Client parallel installiertes, nicht nfs-basiertes Gentoo bekommt über die Init-Scripts problemlos die Netzwerkkonfiguration per dhcp zugespielt. Prinzipiell läuft's also, nur beim Booten ist irgendwie der Wurm drin. Kann's sein, dass mir irgendein Kernelmodul fehlt? Der e1000-Treiber ist fest in den Kernel kompiliert, booten über die interne Karte klappt nach wie vor problemlos.

Hat vielleicht jemand ne Idee, wie ich das trotz Schädel heute noch ans Laufen bringen könnte?  :Wink: 

Edit: Titel angepasst. Nicht viiiieeeel schöner, aber eeetwas treffender.Last edited by sprittwicht on Thu May 24, 2007 11:25 pm; edited 2 times in total

----------

## Robmaster

Kommt mir bekannt vor.

Versuch folgendes 

rc-update del net.eth0 default

In /etc/conf.d/net alles auf eth2 stellen

ln -s /etc/init.d/net.eth0 /etc/init.d/net.eth2

rc-update add net.eth2 default

Hatte ein ähnliches problem ( 1 Netzwerkkarte jedoch nur eth2 und keine Adresse vom DHCPd)

----------

## sprittwicht

Das Problem sind nicht die Init-Scripts. Der Kernel kann ja noch nichtmal das Root-Filesystem mounten, da er seinerseits anscheinend schon Probleme hat, die Karte richtig zu initialisieren.

Ich hab jetzt schätzungsweise 99,9% aller Foreneinträge durchgeackert, die sich irgendwie mit dhcp, nfs und eth*-Chaos befassen. Ich komm auf keinen grünen Zweig.

Unterwegs hab ich aber zumindest die Ursache für die "magische" Benennung neuer eth*-Devices gefunden. Hatte auf meinem Server nach Austausch einer Karte auch plötzlich ein eth2, dafür kein eth0 mehr: In /etc/udev/rules.d/70-persistent-net.rules speichert udev wohl einmal zugewiesene Aliase. Das hatte bei mir unter anderem zur Folge, dass ich auf dem Client mit der zusätzlich eingebauten Karte plötzlich irgendwelche Fehler bekam, dass udev eth1 auf eth0 umbenennen wollte.

Aber zurück zu meinem Problem.  :Smile: 

Nochmal für's Protokoll, auf dem Client sind zwei Gentoo-Systeme installiert:

1. gentoo-sources-2.6.19-r5, x86, bootet komplett von Festplatte und bekommt über die Init-Scripts problemlos eine gültige Netzwerkkonfiguration für die Intel-Karte zugewiesen.

2. gentoo-sources-2.6.20-r8, x86_64 (!), Kernel wird von Festplatte geladen, dann richtet der Kernel selbst per dhcp das Netzwerk ein und mountet das Root-Dateisystem, welches per nfs eingebunden ist.

(2.) funktioniert auf mysteriöse Art und Weise nur mit dem internen Netzwerkchip, ULi Irgendwas mit dem Treiber uli526x.

dmesg sagt folgendes:

```
May 23 09:34:16 knut e1000: 0000:02:00.0: e1000_probe: (PCI Express:2.5Gb/s:Width x1) 00:15:17:21:1f:dd

May 23 09:34:16 knut e1000: eth0: e1000_probe: Intel(R) PRO/1000 Network Connection

May 23 09:34:16 knut uli526x: ULi M5261/M5263 net driver, version 0.9.3 (2005-7-29)

May 23 09:34:16 knut ACPI: PCI Interrupt 0000:00:11.0[A] -> GSI 17 (level, low) -> IRQ 17

May 23 09:34:16 knut eth1: ULi M5263 at pci0000:00:11.0, 00:13:8f:81:7d:7d, irq 17.
```

Der e1000-Treiber wird also anscheinend korrekt initialisiert.

Weiter geht's laut dmesg:

```
May 23 09:34:16 knut ADDRCONF(NETDEV_UP): eth0: link is not ready

May 23 09:34:16 knut ADDRCONF(NETDEV_UP): eth1: link is not ready

May 23 09:34:16 knut Sending DHCP requests .<6>uli526x: eth1 NIC Link is Up 100 Mbps Full duplex

May 23 09:34:16 knut ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready

May 23 09:34:16 knut ., OK

May 23 09:34:16 knut IP-Config: Got DHCP answer from 192.168.0.1, my address is 192.168.0.2

May 23 09:34:16 knut IP-Config: Complete:

May 23 09:34:16 knut device=eth1, addr=192.168.0.2, mask=255.255.255.0, gw=192.168.0.1,

May 23 09:34:16 knut host=192.168.0.2, domain=ranzbude.lan, nis-domain=(none),

May 23 09:34:16 knut bootserver=192.168.0.1, rootserver=192.168.0.1, rootpath=

May 23 09:34:16 knut Looking up port of RPC 100003/3 on 192.168.0.1

May 23 09:34:16 knut Looking up port of RPC 100005/3 on 192.168.0.1

May 23 09:34:16 knut VFS: Mounted root (nfs filesystem) readonly.
```

So sieht's aus, wenn das Netzwerkkabel im ULi steckt.

Steckt das Kabel in der Intel-Karte, endet das Drama folgendermaßen:

```
ADDRCONF(NETDEV_UP): eth0: link is not ready

ADDRCONF(NETDEV_UP): eth1: link is not ready

Sending DHCP requests .<6>uli526x: eth1 NIC Link is Down
```

Womit er Recht hat, eth1 ist down. Aber was ist mit eth0? Jetzt hängt er in einer Endlosschleife: Timeout, Retrying, link not ready, ...

Schlau wie ich bin sehe ich sofort: Kernel 2.6.20 ist schuld. Also einen 2.6.19 auf dem diskless x86_64 kompiliert, der kommt mit dem e1000-Treiber Version 7.2.9-k4. In 2.6.20 werkelt 7.3.15-k2.

Leider bin ich doch nicht so schlau, und was dmesg jetzt mit mir macht, fühlt sich sogar noch deprimierender an (nur noch eth0, weil ich den ULi-Treiber diesmal komplett rausgelassen habe):

```
ADDRCONF(NETDEV_UP): eth0: link is not ready

Sending DHCP requests .<6>e1000: eth0: e1000_watchdog: NIC Link is Up 1000 Mbps Full Duplex

ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready

..<7>eth0: no IPv6 routers present

```

Er sagt also der Link wär da, tut aber trotzdem keinen Pup. Die Meldung "no IPv6 routers present" kommt übrigens immer, auch mit dem funktionierenden Setup mit ULi-Adapter.

Also ich bin jetzt wirklich... Latein -> Ende.

Woran kann's liegen? Läuft der e1000-Treiber auf AMD64-Systemen nicht richtig? Fehlt mir irgendwas im Kernel (macht eigentlich keinen Sinn, finde ich)?

Werde nochmal einen aktuellen ~AMD64-Kernel bauen. Eventuell mit den aktuellsten Treibern von http://sourceforge.net/projects/e1000 patchen (Auch noch nie gemacht. Einfach das "drivers/net/e1000/"-Verzeichnis durch das entpackte Sourceforge-Archiv ersetzen? Verträgt sich ein brandneuer Treiber überhaupt zwangsläufig mit einem älteren Kernel?).

Last but not least noch einen Ausschnitt aus dem Server-Log:

```
May 23 17:04:20 horst e1000: eth2: e1000_watchdog: NIC Link is Down

May 23 17:04:22 horst e1000: eth2: e1000_watchdog: NIC Link is Up 1000 Mbps Full Duplex

May 23 17:05:48 horst e1000: eth2: e1000_watchdog: NIC Link is Down

May 23 17:05:49 horst e1000: eth2: e1000_watchdog: NIC Link is Up 1000 Mbps Full Duplex

May 23 17:07:10 horst e1000: eth2: e1000_watchdog: NIC Link is Down

May 23 17:07:12 horst e1000: eth2: e1000_watchdog: NIC Link is Up 1000 Mbps Full Duplex

May 23 17:08:36 horst e1000: eth2: e1000_watchdog: NIC Link is Down

May 23 17:08:38 horst e1000: eth2: e1000_watchdog: NIC Link is Up 1000 Mbps Full Duplex
```

Das zelebriert er während der erfolglosen Verbindungsversuche der Intel-Karte, auch mit Kernel 2.6.20, wenn er also nicht "link up" auf dem Client meldet und trotzdem scheitert.

----------

## sprittwicht

Tja, Kernel 2.6.21 mit e1000-7.3.20-k2 war dann auch nicht von Erfolg gekrönt.

Und das src-Verzeichnis des aktuellen e1000-Treibers (7.5.5.1) einfach über den kerneleigenen drüberkopieren war auch Mist. Er hat nämlich nur das Modul gebaut, was mir als Nicht-Root-Dateisystembesitzer natürlich nicht weiterhilft.  :Smile: 

Am weitesten komme ich auf meinem nfsroot-System also momentan mit Kernel 2.6.19. Da nimmt er zumindest minimalen Kontakt mit dem Server auf, wie /var/log/messages auf dem Server zeigt:

```
May 23 23:00:34 horst e1000: eth2: e1000_watchdog: NIC Link is Down

May 23 23:00:36 horst e1000: eth2: e1000_watchdog: NIC Link is Up 1000 Mbps Full Duplex

May 23 23:00:42 horst dhcpd: DHCPDISCOVER from 00:15:17:21:1f:dd via eth2

May 23 23:00:42 horst dhcpd: DHCPOFFER on 192.168.0.2 to 00:15:17:21:1f:dd via eth2

May 23 23:00:46 horst dhcpd: DHCPDISCOVER from 00:15:17:21:1f:dd via eth2

May 23 23:00:46 horst dhcpd: DHCPOFFER on 192.168.0.2 to 00:15:17:21:1f:dd via eth2

May 23 23:00:53 horst dhcpd: DHCPDISCOVER from 00:15:17:21:1f:dd via eth2

May 23 23:00:53 horst dhcpd: DHCPOFFER on 192.168.0.2 to 00:15:17:21:1f:dd via eth2

May 23 23:01:06 horst dhcpd: DHCPDISCOVER from 00:15:17:21:1f:dd via eth2

May 23 23:01:06 horst dhcpd: DHCPOFFER on 192.168.0.2 to 00:15:17:21:1f:dd via eth2

May 23 23:01:29 horst dhcpd: DHCPDISCOVER from 00:15:17:21:1f:dd via eth2

May 23 23:01:29 horst dhcpd: DHCPOFFER on 192.168.0.2 to 00:15:17:21:1f:dd via eth2

May 23 23:02:00 horst e1000: eth2: e1000_watchdog: NIC Link is Down

May 23 23:02:02 horst e1000: eth2: e1000_watchdog: NIC Link is Up 1000 Mbps Full Duplex

May 23 23:02:07 horst dhcpd: DHCPDISCOVER from 00:15:17:21:1f:dd via eth2

May 23 23:02:07 horst dhcpd: DHCPOFFER on 192.168.0.2 to 00:15:17:21:1f:dd via eth2

May 23 23:02:13 horst dhcpd: DHCPDISCOVER from 00:15:17:21:1f:dd via eth2

May 23 23:02:13 horst dhcpd: DHCPOFFER on 192.168.0.2 to 00:15:17:21:1f:dd via eth2

May 23 23:02:25 horst dhcpd: DHCPDISCOVER from 00:15:17:21:1f:dd via eth2

May 23 23:02:25 horst dhcpd: DHCPOFFER on 192.168.0.2 to 00:15:17:21:1f:dd via eth2

May 23 23:02:45 horst dhcpd: DHCPDISCOVER from 00:15:17:21:1f:dd via eth2

May 23 23:02:45 horst dhcpd: DHCPOFFER on 192.168.0.2 to 00:15:17:21:1f:dd via eth2

May 23 23:03:16 horst e1000: eth2: e1000_watchdog: NIC Link is Down

May 23 23:03:18 horst e1000: eth2: e1000_watchdog: NIC Link is Up 1000 Mbps Full Duplex

May 23 23:03:24 horst dhcpd: DHCPDISCOVER from 00:15:17:21:1f:dd via eth2

May 23 23:03:24 horst dhcpd: DHCPOFFER on 192.168.0.2 to 00:15:17:21:1f:dd via eth2

May 23 23:03:31 horst dhcpd: DHCPDISCOVER from 00:15:17:21:1f:dd via eth2

May 23 23:03:31 horst dhcpd: DHCPOFFER on 192.168.0.2 to 00:15:17:21:1f:dd via eth2

May 23 23:03:45 horst dhcpd: DHCPDISCOVER from 00:15:17:21:1f:dd via eth2

May 23 23:03:45 horst dhcpd: DHCPOFFER on 192.168.0.2 to 00:15:17:21:1f:dd via eth2

May 23 23:04:09 horst dhcpd: DHCPDISCOVER from 00:15:17:21:1f:dd via eth2

May 23 23:04:09 horst dhcpd: DHCPOFFER on 192.168.0.2 to 00:15:17:21:1f:dd via eth2
```

Mehr ist nicht drin, warum nur?

Übrigens liegt's nicht an dem Umstand, dass dhcp beim Booten nicht klappt. Wenn ich dem Kernel direkt den Bootparameter "ip=192.168.0.2:192.168.0.1:192.168.0.1:255.255.255.0:knut:eth0:off" mit auf den Weg gebe, übernimmt er zwar angeblich die Konfiguration, kann aber trotzdem keine Verbindung zum nfs-Server herstellen.

Nochmal ein paar Ausgaben, wenn ich über den ULi boote. Der e1000-Treiber ist zumindest irgendwie anwesend:

ifconfig -a:

```
eth0      Protokoll:Ethernet  Hardware Adresse 00:15:17:21:1F:DD

          BROADCAST MULTICAST  MTU:1500  Metric:1

          RX packets:0 errors:0 dropped:0 overruns:0 frame:0

          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0

          Kollisionen:0 Sendewarteschlangenlänge:1000

          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)

          Basisadresse:0xcc00 Speicher:fe8e0000-fe900000

eth1      Protokoll:Ethernet  Hardware Adresse 00:13:8F:81:7D:7D

          inet Adresse:192.168.0.2  Bcast:192.168.0.255  Maske:255.255.255.0

          inet6 Adresse: fe80::213:8fff:fe81:7d7d/64 Gültigkeitsbereich:Verbindung

          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

          RX packets:173272 errors:0 dropped:0 overruns:0 frame:0

          TX packets:119123 errors:0 dropped:0 overruns:0 carrier:0

          Kollisionen:0 Sendewarteschlangenlänge:1000

          RX bytes:152218057 (145.1 Mb)  TX bytes:37141735 (35.4 Mb)

          Interrupt:17 Basisadresse:0xe800

lo        Protokoll:Lokale Schleife

          inet Adresse:127.0.0.1  Maske:255.0.0.0

          UP LOOPBACK RUNNING  MTU:16436  Metric:1

          RX packets:100 errors:0 dropped:0 overruns:0 frame:0

          TX packets:100 errors:0 dropped:0 overruns:0 carrier:0

          Kollisionen:0 Sendewarteschlangenlänge:0

          RX bytes:7560 (7.3 Kb)  TX bytes:7560 (7.3 Kb)

sit0      Protokoll:IPv6-nach-IPv4

          NOARP  MTU:1480  Metric:1

          RX packets:0 errors:0 dropped:0 overruns:0 frame:0

          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0

          Kollisionen:0 Sendewarteschlangenlänge:0

          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)
```

Sollte es mich verwirren, dass eth0 kein Interrupt zugeordnet ist?

ethtool eth0:

```
Settings for eth0:

        Supported ports: [ TP ]

        Supported link modes:   10baseT/Half 10baseT/Full

                                100baseT/Half 100baseT/Full

                                1000baseT/Full

        Supports auto-negotiation: Yes

        Advertised link modes:  10baseT/Half 10baseT/Full

                                100baseT/Half 100baseT/Full

                                1000baseT/Full

        Advertised auto-negotiation: Yes

        Speed: Unknown! (65535)

        Duplex: Unknown! (255)

        Port: Twisted Pair

        PHYAD: 0

        Transceiver: internal

        Auto-negotiation: on

        Supports Wake-on: umbg

        Wake-on: d

        Current message level: 0x00000007 (7)

        Link detected: no
```

ethtool -i eth0:

```
driver: e1000

version: 7.3.15-k2

firmware-version: 5.11-10

bus-info: 0000:02:00.0
```

----------

## sprittwicht

Problem gelöst!  :Smile: 

Hab mal die funktionierende Kernelkonfiguration per "make oldconfig" samt minimal notwendiger Anpassungen (x86 -> x86_64) auf das Diskless-System übernommen und siehe da: es lief!

Dann die Unterschiede zwischen der funktionierenden und der kaputten Version angeschaut und nach und nach hinzugekommene Optionen per Bootparameter ausgeschaltet. Als Übeltäter hat sich CONFIG_PCI_MSI entpuppt, der in den x86_64-Kernel aktiviert war, im x86-Kernel nicht. Starte ich meinen 2.6.20-Kernel mit der Bootoption "pci=nomsi", bootet auch er brav nach Vorschrift.

Ist das jetzt ein Bug im e1000-Treiber oder einfach nur meine Blödheit, unbewusst MSI eingeschaltet zu haben, und ich hätte das - irgendwie(TM) - wissen müssen?

Zitat:

```
#

# PCI configuration

#

config PCI_MSI

        bool "Message Signaled Interrupts (MSI and MSI-X)"

        depends on PCI

        depends on (X86_LOCAL_APIC && X86_IO_APIC) || IA64

        help

           This allows device drivers to enable MSI (Message Signaled

           Interrupts).  Message Signaled Interrupts enable a device to

           generate an interrupt using an inbound Memory Write on its

           PCI bus instead of asserting a device IRQ pin.

           Use of PCI MSI interrupts can be disabled at kernel boot time

           by using the 'pci=nomsi' option.  This disables MSI for the

           entire system.

           If you don't know what to do here, say N.
```

Liest sich für mich doch nach einer Option, die der Kernel dem Treiber anbietet, aber es ist Sache des Treibers, ob er davon Gebrauch machen will oder nicht. Oder interpretier ich das falsch?

In dem Fall sollte der e1000-Treiber wohl auf MSI verzichten...

----------

