sk(4) und erweiterte Hardware-Features

rMarkus

rMarkus

Chuck The Plant
Hallo,

heute wollte ich eine D-Link DGE-530T ausprobieren und habe verwundert vestgestellt, dass der verwendete Chip (Marvel Yokon) keine erweiterten Features unterstuetzt.

Das aktuelle Betriebssystem ist FreeBSD 6.0-RELEASE-p4.

dmesg
Code: 
skc0: <D-Link DGE-530T Gigabit Ethernet> port 0xd800-0xd8ff mem 0xef800000-0xef8
03fff irq 9 at device 11.0 on pci2
skc0: DGE-530T Gigabit Ethernet Adapter rev. (0x1)
sk0: <Marvell Semiconductor, Inc. Yukon> on skc0
sk0: Ethernet address: 00:0f:3d:f3:e1:06
miibus0: <MII bus> on sk0
...
sk0: link state changed to UP


ifconfig -a
Code: 
sk0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
        inet 192.168.32.29 netmask 0xffffff00 broadcast 192.168.32.255
        inet6 fe80::20f:3dff:fef3:e106%sk0 prefixlen 64 scopeid 0x1
        ether 00:0f:3d:f3:e1:06
        media: Ethernet autoselect (1000baseTX <full-duplex,flag0,flag1>)
        status: active

Unter FreeBSD 6.1 PRERELEASE (RELENG_6 vom Freitag 2006-03-10) wurde immerhin "options=8<VLAN_MTU>" angezeigt.

Nach meinen Erinnerungen konnte die 3com2000 mit dem gleichen (?) Chip sogar folgendes: options=b<RXCSUM,TXCSUM,VLAN_MTU>.

Wird die Chip-Revision vielleicht nicht richtig unterstützt?
 
Ach ja, der gute Treiber. Ich habe ihn auf verschiedenen karten (3Com 3C2000 und Marvell OnBoard) probiert, auf beiden lief er eher schlecht als recht. Erst schien alles gut, die Karte wurde schneller, es wurden mehr Features angeboten. Doch nach einiger Zeit (4 - 6h) wurde der Link instabil, die Verbindung zum Switch riss regelmäßig ab. Der Reboot machte es dann wieder gut, was aber natürlich keine Lösung ist. Ich habe dann eine bis heute unbeantwortete Mail an den Support von Marvell geschickt und nutzt wieder sk.
 
Hallo Yamagi,

ich meine mich aber düster erinnern zu können, dass HW-Checksum früher (FreeBSD 5.x) mal bei sk(4) aktiv war, oder?

Bei einigen Chips wie xl(4) oder bge(4) wurde im Laufe der Zeit HW-Checksum wegen Problemen wieder deaktiviert, evtl. war das auch der Grund.
 
Vergleich D-Link DGE-530T und 3Com2000

D-Link DGE-530T (Rev. A1)
Chip: Marvell 88E8003-LKJ

Code: 
skc0: <D-Link DGE-530T Gigabit Ethernet> port 0x1400-0x14ff mem 0xf4000000-0xf40              03fff irq 7 at device 16.0 on pci0
skc0: DGE-530T Gigabit Ethernet Adapter
sk0: <Marvell Semiconductor, Inc. Yukon> on skc0
sk0: Ethernet address: 00:0f:3d:f3:e1:06
miibus1: <MII bus> on sk0
e1000phy0: <Marvell 88E1000 Gigabit PHY> on miibus1
e1000phy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX-FDX, auto


3Com2000-T
Chip: 3Com/Marvell 940-MV00-BGA

Code: 
skc1: <3Com 3C940 Gigabit Ethernet> port 0x1800-0x18ff mem 0xf4004000-0xf4007fff               irq 5 at device 18.0 on pci0
skc1: 3Com Gigabit NIC (3C2000)
sk1: <Marvell Semiconductor, Inc. Yukon> on skc1
sk1: Ethernet address: 00:0a:5e:1a:14:20
miibus2: <MII bus> on sk1
e1000phy1: <Marvell 88E1000 Gigabit PHY> on miibus2
e1000phy1:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX-FDX, auto

Beide haben kein Checksum-Offload oder erweiterte Features mit dem sk(4) von FreeBSD 5.3.
Bei FreeBSD 6.1 PRERELEASE gibt's zumindest bei der D-Link "VLAN-MTU" dazu, mehr aber nicht.

So richtig überzeugt mich sk(4) nicht, bge(4) läuft wirklich anständig und em(4) hätte mehr Features.

Unter FreeBSD 5.3 kann ich eine der beiden sk-Devices nicht mit ifconfig configurieren, das scheint ein zusaetzlicher Bug zu sein.

PS: Die D-Link DGE-530T läuft aber im Gegensatz zur 3Com2000-T auf Intel 440BX-Chipsätzen. Vermutlich liegt es daran, dass die D-Link durch einen zusätzlichen Spannungswandler sich selbst die 3,3 Volt erzeugt, während die 3Com auf eine Versorgung vom PCI-Bus angewiesen ist.
 
ich meine mich aber düster erinnern zu können, dass HW-Checksum früher (FreeBSD 5.x) mal bei sk(4) aktiv war, oder?
Zum Vergrößern anklicken....
Ja, das wurde aufgrund von Problemen irgendwann im Kernel auskommentiert. Könnte bei 5.2.1 passiert sein.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben