Internet nach Kernel Kompilation langsam

[rotalever]

Bisher habe ich immer die Standard Debian Kernel benutzt. Aufgrund der neuen NVidia Treiber und dem Wunsch nach einer Framebuffer-Konsole habe ich einen Kernel selbst kompiliert. Funktioniert auch alles ganz hervorragend, bis auf das Internet. Mir scheint, dass sowohl surfen als auch downloaden und pings langsamer geworden sind. Es ist nicht mehr so flüssig wie früher.
Wenn ich z.B. meinen Router anpinge ist es manchmal noch einigermaßen normal mit 7.xx ms, wobei ich früher bessere Werte hatte. Aber > 100ms ist dann doch eindeutig zu viel und kam früher nie vor.

64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=1150 ms
64 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=150 ms
64 bytes from 192.168.1.1: icmp_seq=3 ttl=64 time=6484 ms
64 bytes from 192.168.1.1: icmp_seq=4 ttl=64 time=5485 ms
64 bytes from 192.168.1.1: icmp_seq=5 ttl=64 time=4485 ms
64 bytes from 192.168.1.1: icmp_seq=6 ttl=64 time=3485 ms
64 bytes from 192.168.1.1: icmp_seq=7 ttl=64 time=2485 ms
64 bytes from 192.168.1.1: icmp_seq=8 ttl=64 time=1485 ms
64 bytes from 192.168.1.1: icmp_seq=9 ttl=64 time=486 ms
64 bytes from 192.168.1.1: icmp_seq=10 ttl=64 time=239 ms
64 bytes from 192.168.1.1: icmp_seq=11 ttl=64 time=7.30 ms
64 bytes from 192.168.1.1: icmp_seq=12 ttl=64 time=7.29 ms
64 bytes from 192.168.1.1: icmp_seq=13 ttl=64 time=12468 ms
64 bytes from 192.168.1.1: icmp_seq=14 ttl=64 time=11468 ms
64 bytes from 192.168.1.1: icmp_seq=15 ttl=64 time=10468 ms
64 bytes from 192.168.1.1: icmp_seq=16 ttl=64 time=9468 ms
64 bytes from 192.168.1.1: icmp_seq=17 ttl=64 time=8469 ms
64 bytes from 192.168.1.1: icmp_seq=18 ttl=64 time=7469 ms
64 bytes from 192.168.1.1: icmp_seq=19 ttl=64 time=6469 ms
64 bytes from 192.168.1.1: icmp_seq=20 ttl=64 time=5469 ms
64 bytes from 192.168.1.1: icmp_seq=21 ttl=64 time=4470 ms
64 bytes from 192.168.1.1: icmp_seq=22 ttl=64 time=3470 ms
64 bytes from 192.168.1.1: icmp_seq=23 ttl=64 time=2470 ms
64 bytes from 192.168.1.1: icmp_seq=24 ttl=64 time=1470 ms
64 bytes from 192.168.1.1: icmp_seq=25 ttl=64 time=471 ms

Wenn ich das System starte sagt er, dass er die Netzwerkkarte auf 100Mbit/s full duplex eingestellt hat, daran kann es wohl nicht liegen. Im Moment weiß ich nicht mehr weiter...

Ich hab mal die Kernel Konfiguration angehängt, vll. gibt es da ja einen Anhaltspunkt?

[Simon]

Hallo,

Aufgrund der neuen NVidia Treiber
Kernel Headers passend zum verwendeten Kernel installieren hätte gereicht ;) Und eventuell den GCC...

dem Wunsch nach einer Framebuffer-Konsole
Der tut doch mit dem Debian Standard Kernel? Einfach beim Booten "vga=xxx" übergeben :confused:

Wenn ich z.B. meinen Router anpinge ist es manchmal noch einigermaßen normal mit 7.xx ms, wobei ich früher bessere Werte hatte. Aber > 100ms ist dann doch eindeutig zu viel und kam früher nie vor.
Ist die CPU denn völlig ausgelastet oder im Leerlauf?

[rotalever]

Naja ich wollte sowieso lieber nen selbst kompilierten Kernel haben... Zudem hab ich beim vorkompilierten nicht diese schönen Fonts im Framebuffer.
Also beim pingen auf den Router ist die Auslastung vll. bei 1-2% -> leerlauf.

[rotalever]

Hab noch folgendes entdeckt, könnte das weiterhelfen?
dmesg:
ADDRCONF(NETDEV_UP): eth0: link is not ready
e100: eth0: e100_watchdog: link up, 100Mbps, full-duplex
ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
eth0: no IPv6 routers present
NETDEV WATCHDOG: eth0: transmit timed out
e100: eth0: e100_watchdog: link up, 100Mbps, full-duplex
[...]
NETDEV WATCHDOG: eth0: transmit timed out
e100: eth0: e100_watchdog: link up, 100Mbps, full-duplex
i2c_adapter i2c-0: Transaction error!
ADDRCONF(NETDEV_UP): eth0: link is not ready
e100: eth0: e100_watchdog: link up, 100Mbps, full-duplex
ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
e100: eth0: e100_watchdog: link up, 100Mbps, full-duplex
eth0: no IPv6 routers present

[Gast]

Könnte damit zusammenhängen. Schmeiß die IPv6-Unterstützung aus deinem Kernel raus, die brauchst du sowieso nicht.

[rotalever]

Ich hab jetzt erstmal unter
Networking -> Networking Options -> IP:tunneling
aktiviert und die IPv6-Geschichten als Modul kompiliert. Es hat sich aber nicht gebessert und dmesg meldet immer noch "eth0: no IPv6 routers present". Ich meine mich aber auch zu erinnern, dass früher beim Starten eine Meldung wie " ipv4 over ipv6 tunneling driver" stand. Das kommt jetzt gar nicht mehr.

In der Konfiguration sehe ich gerade, dass "IPv6: IPv6-in-IPv4 tunnel (SIT driver)" als Modul kompiliert wurde. Wenn ich ein "modprobe sit" mache wird es laut dmesg Aussage "IPv6 over IPv4 tunneling driver" geladen. Allerdings ändert sich an den PING-Zeiten zum Router gar nichts.

[rotalever]

IPv6 mal ganz rausgenommen: Immernoch das selbe Problem. :confused:
dmesg meldet jetzt natürlich nicht mehr "eth0: no IPv6 routers present".

[gentoo]

Hi -Teste mal folgendes

* tulip - Support brauchst du nicht
* setz den Intel Pro ChipSupport auf module
* unter "Library Routines" aktivier die Option CRC-CCITT

lg,
gentoo

[rotalever]

Hab alles so gemacht -> nichts hat sich verändert...
Und es liegt wirklich am Kernel da ich noch mal den alten getestet habe und da geht alles.

[gentoo]

Schon mal den 2.6.18er getestet - vielleicht liegts ja nicht an der config
sondern am kernel ??

[rotalever]

Das könnte natürlich sein, ich werd ihn mal laden und dann kompilieren..

[rotalever]

Ok der Fehler war mal wieder ein Klassiker: IRQs... :|
Im Rahmen eines anderen IRQ Fehlers mit der Grafikkarte hatte ich mal für die Netzwerkkarte im BIOS IRQ#7 eingestellt und war zu faul wieder auf AUTO zurückzustellen. Das mag der Kernel wohl nicht so ganz.... Denn jetzt läuft es mit dem 2.6.19 wieder rund. Der 2.6.18 ist übrigens beim starten hängen geblieben, aber das ist ja jetzt egal, wo 2.6.19 läuft.

[gentoo]

Da kommt sich der Kernel mit dem BIOS in die Haare,
wenns ums Thema IRQ-Verwaltung geht. ;)

Viel Spass dann noch mit deinem neuen selbstgebauten Kernel.

lg,
gentoo

[rotalever]

Viel Spass dann noch mit deinem neuen selbstgebauten Kernel.
Danke ;)