Netwerk wil niet op 1 GBit

[de-snader]

Ik heb het volgende probleem: Mijn thuisservertje wil niet verbinding maken met het netwerk op 1 GBit.

OS: Ubuntu 9.04
Netwerkkaart: Intel Corporation 82541PI Gigabit Ethernet Controller (rev 05)
Switch: NetGear GS105

Op auto-connect schakelt de switch naar 10 MBit, terwijl mii-tool het volgende resultaat geeft:

code:

root@dev1:~# mii-tool
eth0: negotiated 100baseTx-FD, link ok
eth1: negotiated 1000baseT-FD flow-control, link ok

Echter komt de verbinding niet boven de 10 MBit uit. Wanneer ik de snelheid handmatig instel met behulp van ethtool loop ik tegen het volgende aan:

100 MBit: Switch geeft aan 100 MBit, server geeft aan dat er geen verbinding is
1000 MBit: Geen verbinding met switch

De volgende zaken heb ik al uitgesloten:

- Kabel werkt op een andere netwerkkaart wel op 1 GBit.
- Op een 100 MBit switch schakelt 'ie automatisch naar 100 MBit
- Andere pc's werken wel met 1 GBit

Heeft er iemand een idee hoe ik mijn server alsnog op 1 GBit kan krijgen?

[Saturnus]

Misschien vergelijkbaar met [Ubuntu] Netgear GA311 achter switch werkt niet.?
Oftewel probeer die andere soort kabel eens. Ik moet eerlijk zeggen dat ik er nog steeds geen tijd ingestoken heb.

[AlterMann]

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/309211
En dan voornamelijk deze post: https://bugs.launchpad.ne...x/+bug/309211/comments/13

1e hit op google..

[de-snader]

AlterMann schreef op zaterdag 27 juni 2009 @ 07:11:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/309211
En dan voornamelijk deze post: https://bugs.launchpad.ne...x/+bug/309211/comments/13

1e hit op google..

Ben hier een tijdje mee bezig geweest, maar krijg steeds dat na verloop van tijd de netwerkverbinding op de server vast loopt tijdens het kopieren van grote hoeveelheden data.

Ik heb het probleem nu maar omzeilt door de Onboard NIC te gebruiken voor het interne verkeer en de Intel-kaart te verbinden met mijn kabelmodem. Zo werkt alles wel zoals het hoort, maar is wel jammer van de redelijk dure Intel kaart...

[de-snader]

[update]

Netwerk lijkt toch niet zo stabiel te zijn als ik dacht... Elke vastloper gebeurt wanneer ik via mijn workstation op de server bestanden aan het sorteren ben. De share's zijn gemaakt via NFS, en gemount op mijn workstation via /etc/fstab

Zowel de server als mijn workstation maken gebruik van Ubuntu 9.04. Doordat de netwerkverbinding in 1x vast loopt, blijft ook Bestandsbeheer even hangen. Na op de server de de netwerkverbindingen opnieuw opgestart te hebben, werkt alles weer.

Hieronder staan de gegevens hiervan uit kern.log

code:

Jun 29 21:11:04 dev1 kernel: [89117.010131] ------------[ cut here ]------------
Jun 29 21:11:05 dev1 kernel: [89117.010139] WARNING: at /build/buildd/linux-2.6.28/net/sched/sch_generic.c:226 dev_watchdog+0x270/0x280()
Jun 29 21:11:05 dev1 kernel: [89117.010144] NETDEV WATCHDOG: eth0 (r8169): transmit timed out
Jun 29 21:11:05 dev1 kernel: [89117.010148] Modules linked in: video output input_polldev nfsd auth_rpcgss exportfs nfs lockd nfs_acl sunrpc ip6table_filter ip6_tables iptable_raw xt_comment xt_recent xt_policy ipt_ULOG ipt_TTL ipt_ttl ipt_REJECT ipt_REDIRECT ipt_NETMAP ipt_MASQUERADE ipt_LOG ipt_ECN ipt_ecn ipt_CLUSTERIP ipt_ah ipt_addrtype nf_nat_tftp nf_nat_snmp_basic nf_nat_sip nf_nat_pptp nf_nat_proto_gre nf_nat_irc nf_nat_h323 nf_nat_ftp nf_nat_amanda ts_kmp nf_conntrack_amanda nf_conntrack_tftp nf_conntrack_sip nf_conntrack_proto_sctp nf_conntrack_pptp nf_conntrack_proto_gre nf_conntrack_netlink nf_conntrack_netbios_ns nf_conntrack_irc nf_conntrack_h323 nf_conntrack_ftp xt_tcpmss xt_pkttype xt_physdev xt_owner xt_NFQUEUE xt_NFLOG xt_multiport xt_MARK xt_mark xt_mac xt_limit xt_length xt_iprange xt_helper xt_hashlimit xt_DSCP xt_dscp xt_dccp xt_conntrack xt_CONNMARK xt_connmark xt_CLASSIFY xt_tcpudp xt_state iptable_nat nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_conntrack iptable_mangle nfnetlink iptabl
Jun 29 21:11:05 dev1 kernel: _filter ip_tables x_tables lp parport arc4 ecb rt61pci crc_itu_t rt2x00pci rt2x00lib led_class mac80211 cfg80211 eeprom_93cx6 psmouse serio_raw pcspkr k8temp i2c_piix4 shpchp e1000 r8169 mii raid10 raid456 async_xor async_memcpy async_tx xor raid1 raid0 multipath linear fbcon tileblit font bitblit softcursor
Jun 29 21:11:05 dev1 kernel: [89117.010303] Pid: 0, comm: swapper Not tainted 2.6.28-11-server #42-Ubuntu
Jun 29 21:11:05 dev1 kernel: [89117.010307] Call Trace:
Jun 29 21:11:05 dev1 kernel: [89117.010312]  <IRQ>  [<ffffffff80250927>] warn_slowpath+0xb7/0xf0
Jun 29 21:11:05 dev1 kernel: [89117.010332]  [<ffffffff80606500>] ? arp_process+0x70/0x7c0
Jun 29 21:11:05 dev1 kernel: [89117.010339]  [<ffffffff8069dd49>] ? _spin_lock+0x9/0x10
Jun 29 21:11:05 dev1 kernel: [89117.010346]  [<ffffffff80416a2a>] ? __next_cpu+0x1a/0x30
Jun 29 21:11:05 dev1 kernel: [89117.010355]  [<ffffffff802424b2>] ? enqueue_entity+0x122/0x2b0
Jun 29 21:11:05 dev1 kernel: [89117.010361]  [<ffffffff802486cd>] ? enqueue_task_fair+0x3d/0x80
Jun 29 21:11:05 dev1 kernel: [89117.010367]  [<ffffffff8023e6a0>] ? enqueue_task+0x50/0x60
Jun 29 21:11:05 dev1 kernel: [89117.010373]  [<ffffffff8024a58d>] ? default_wake_function+0xd/0x10
Jun 29 21:11:05 dev1 kernel: [89117.010381]  [<ffffffff802688a1>] ? autoremove_wake_function+0x11/0x40
Jun 29 21:11:05 dev1 kernel: [89117.010389]  [<ffffffff8041cd0a>] ? strlcpy+0x4a/0x60
Jun 29 21:11:05 dev1 kernel: [89117.010394]  [<ffffffff805caf70>] dev_watchdog+0x270/0x280
Jun 29 21:11:05 dev1 kernel: [89117.010401]  [<ffffffff80264bac>] ? __queue_work+0x3c/0x50
Jun 29 21:11:05 dev1 kernel: [89117.010406]  [<ffffffff805cad00>] ? dev_watchdog+0x0/0x280
Jun 29 21:11:05 dev1 kernel: [89117.010413]  [<ffffffff8025bdf9>] run_timer_softirq+0x179/0x260
Jun 29 21:11:05 dev1 kernel: [89117.010423]  [<ffffffff802736bf>] ? clockevents_program_event+0x4f/0x90
Jun 29 21:11:05 dev1 kernel: [89117.010429]  [<ffffffff80256a5c>] __do_softirq+0x9c/0x170
Jun 29 21:11:05 dev1 kernel: [89117.010436]  [<ffffffff80213d8c>] call_softirq+0x1c/0x30
Jun 29 21:11:05 dev1 kernel: [89117.010442]  [<ffffffff80214ffd>] do_softirq+0x5d/0xa0
Jun 29 21:11:05 dev1 kernel: [89117.010447]  [<ffffffff802567dd>] irq_exit+0x8d/0xa0
Jun 29 21:11:05 dev1 kernel: [89117.010455]  [<ffffffff80227658>] smp_apic_timer_interrupt+0x88/0xc0
Jun 29 21:11:05 dev1 kernel: [89117.010461]  [<ffffffff80213668>] apic_timer_interrupt+0x88/0x90
Jun 29 21:11:05 dev1 kernel: [89117.010465]  <EOI>  [<ffffffff8022e856>] ? native_safe_halt+0x6/0x10
Jun 29 21:11:05 dev1 kernel: [89117.010480]  [<ffffffff8021a9fd>] ? default_idle+0x4d/0x50
Jun 29 21:11:05 dev1 kernel: [89117.010486]  [<ffffffff8021aa51>] ? c1e_idle+0x51/0x130
Jun 29 21:11:05 dev1 kernel: [89117.010492]  [<ffffffff806a1085>] ? atomic_notifier_call_chain+0x15/0x20
Jun 29 21:11:05 dev1 kernel: [89117.010501]  [<ffffffff80210e85>] ? cpu_idle+0x65/0xc0
Jun 29 21:11:05 dev1 kernel: [89117.010508]  [<ffffffff806987a3>] ? start_secondary+0x9e/0xcb
Jun 29 21:11:05 dev1 kernel: [89117.010513] ---[ end trace 51ce6b773ee29633 ]---
Jun 29 21:11:05 dev1 kernel: [89117.051416] r8169: eth0: link up

Iemand een idee waar ik dit moet zoeken? Het is nu dus niet de Intel kaart die voor problemen zorgt maar de onboard NIC...

code:

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

[Rainmaker]

Je zou de driver van de onboard NIC kunnen blacklisten, maar ik betwijfel of je andere kaart dan ineens op 1Gb wil gaan hollen.

[de-snader]

Rainmaker schreef op maandag 29 juni 2009 @ 22:59:
Je zou de driver van de onboard NIC kunnen blacklisten, maar ik betwijfel of je andere kaart dan ineens op 1Gb wil gaan hollen.

Ik gebruik de onboard NIC inmiddels als GBit verbinding, en de Intel als 100 MBit. Echter heb ik nog steeds dat de verbinding steeds wegvalt (zie bovenstaande post)

[koffiedrinker]

Dat ligt aan je onboard NIC. Op internet zijn meer mensen te vinden met problemen met deze NIC.
Zelf heb ik er ook een en die is ook niet stabiel te krijgen in de kernel versie 2.6.27 en verder.
Vanaf kernel 2.6.27 is er een nieuwe driver in de kernel terecht gekomen en veroorzaakt volgens mij het probleem.
Zelf ben ik (tijdelijk) terug gegaan naar 2.6.26 en alles draait perfect. De verbindingen lopen op 1 Gbit en er zijn geen vastlopers meer bij grote overdracht van bestanden via NFS.

[Verwijderd]

Is die realtek dan echt de kern van het probleem? Ik heb laatst een linksys gigabit router aangeschaft en sindsdien is NFS ook bij mij een ramp. Vreemd genoeg werkte het wel perfect zolang ik gewoon een gigabit switch aan een 100mbps routertje had hangen; voor het overige was alles identiek (realtek nics, Ubuntu 9.04, kernel, cat6 kabels, NFS-instellingen, etc.). En pas sinds die nieuwe router is mijn pci gigabit kaart (ASUS NX, sundance driver) teruggevallen op 100mbps...Vreemd is ook dat ik nagenoeg geen problemen ondervind met FTP. Het ziet er naar uit dat die problemen alleen met heel specifieke routers optreden.

Momenteel loopt het weer enigszins, maar nog steeds trager als voorheen. Ik moest gewoon de mtu van de netwerkkaarten expliciet op een waarde zetten die <= de mtu van de router is.

De r8169 driver heeft trouwens al langer een dubieuze reputatie; in het verleden heb ik die meermaals verwijderd en vervangen door de driver van realtek zelf. Jammer genoeg zijn ze daar altijd bijzonder slordig en moet er altijd wel iets gepatcht worden.

[ Voor 23% gewijzigd door Verwijderd op 01-07-2009 23:17 ]