Bug 71229
| Summary: | Device sk0 hands up when data transfering [6-CURRENT] | ||
|---|---|---|---|
| Product: | Base System | Reporter: | hunreal |
| Component: | kern | Assignee: | Bjoern A. Zeeb <bz> |
| Status: | Closed FIXED | ||
| Severity: | Affects Only Me | ||
| Priority: | Normal | ||
| Version: | 6.0-CURRENT | ||
| Hardware: | Any | ||
| OS: | Any | ||
|
Description
hunreal
2004-09-01 08:10:26 UTC
See also kern/69879. I can confirm this exact behaviour on other vendors' motherboards,
particularly Gigabyte. The chipset in question:
===
skc0: <Marvell Gigabit Ethernet> port 0xa000-0xa0ff mem 0xf9044000-0xf9047fff irq 20 at device 9.0 on pci1
skc0: Yukon Gigabit Ethernet 10/100/1000Base-T Adapter
sk0: <Marvell Semiconductor, Inc. Yukon> on skc0
sk0: Ethernet address: 00:0f:ea:31:f0:ee
miibus1: <MII bus> on sk0
e1000phy0: <Marvell 88E1000 Gigabit PHY> on miibus1
e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX-FDX, auto
skc0@pci1:9:0: class=0x020000 card=0xe0001458 chip=0x432011ab rev=0x13 hdr=0x00
vendor = 'Marvell Semiconductor (Was: Galileo Technology Ltd)'
device = '88E8001 Gigabit 32-bit Ethernet Controller with Integrated PHY'
class = network
subclass = ethernet
===
The errors in question when doing large transfers:
===
Nov 4 23:51:57 icarus kernel: sk0: discard frame w/o leading ethernet header (len 0 pkt len 0)
Nov 4 23:51:57 icarus kernel: sk0: discard oversize frame (ether type 0 flags 3 len 9022 > max 1514)
Nov 4 23:51:57 icarus kernel: sk0: discard oversize frame (ether type 0 flags 3 len 1556 > max 1514)
Nov 4 23:51:57 icarus kernel: sk0: discard frame w/o leading ethernet header (len 0 pkt len 0)
Nov 4 23:51:57 icarus kernel: sk0: discard oversize frame (ether type 0 flags 3 len 9022 > max 1514)
Nov 4 23:51:57 icarus kernel: sk0: discard oversize frame (ether type 0 flags 3 len 7524 > max 1514)
Nov 4 23:51:57 icarus kernel: sk0: discard oversize frame (ether type e889 flags 3 len 9022 > max 1514)
Nov 4 23:51:57 icarus kernel: sk0: discard oversize frame (ether type eb3a flags 3 len 3840 > max 1514)
...and so on...
===
Operating system is 5.3-RELEASE (as of Nov 5 2004 -- today).
I have managed to circumvent this problem by forcing the sk0 interface
to 100baseTX + full-duplex instead of autodetect (which normally picks up
1000baseTX + full-duplex, since it's connected to a GbE switch).
This is definitely looking to be some sort-of driver problem, and IMHO
has very little to do with motherboard BIOS revisions as implied in the
aforementioned PR (kern/69879). kern/69789, IMHO, should have never
been closed.
--
| Jeremy Chadwick jdc at parodius.com |
| Parodius Networking http://www.parodius.com/ |
| UNIX Systems Administrator Mountain View, CA, USA |
| Making life hard for others since 1977. |
State Changed From-To: open->feedback Patches have been committed to HEAD which should help. Please give them a try and let us know if the probelms are gone? Responsible Changed From-To: freebsd-bugs->bz mine... I confirm that it happens also on FreeBSD RELENG_5_3 (p2 from Dec 8 =
2004) Gigabyte and ASUS P4P800 SE motherboards (Intel 865PE chipset and =
on-board Marvell 88E8001 NIC). I've noticed that only the following =
messages appers in the messages system log:
Dec 13 21:24:10 myhost kernel: sk0: discard frame w/o leading ethernet =
header (len 0 pkt len 0)
and only on tcp sender doing massive bulk data transfer when NIC is set =
to 1000baseTX (other options:=20
sk0: flags=3D8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
(...)
media: Ethernet autoselect (1000baseTX =
<full-duplex,flag0,flag1>)
Heinz Knocke
State Changed From-To: feedback->closed A patch has been applied to if_sk.c in HEAD and MFCed to RELENG_5 and Heinz Knocke confirmed that jumbo frame support now works. Thanks for reporting and testing. |
