I had a motherboard failure and replaced it with the following results.

New mainboard is Asus A7V880 with KT880/VT8237 chipset, Athlon 2800+
processor.  User Manual says it has Marvell 88E8001 Lan Controller.
Marvell.com says this is a 32-bit Yukon controller with Alaska PHY.

This kernel
Nov  3 07:10:46 aurora /netbsd: NetBSD 2.0_RC2 (AURORA) #0: Mon Nov  1 00:04:23 MST 2004
is GENERIC with viapm and viaenv enabled.

And sk detects as:
Nov  3 07:10:46 aurora /netbsd: skc0 at pci0 dev 9 function 0: irq 10
Nov  3 07:10:46 aurora /netbsd: skc0: Yukon Gigabit Ethernet 10/100/1000Base-T Adapter
Nov  3 07:10:46 aurora /netbsd: sk0 at skc0 port A: Ethernet address 00:11:2f:75:bb:34
Nov  3 07:10:46 aurora /netbsd: makphy0 at sk0 phy 0: Marvell 88E1011 Gigabit PHY, rev. 5
Nov  3 07:10:46 aurora /netbsd: makphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto

This kernel hangs after < 13MB.  Ifconfig sk0 down; ifconfig sk0 up a
couple of times restores connectivity briefly as mentioned by others in
various places.

Switching src to HEAD gets this kernel
Nov  5 19:57:02 aurora /netbsd: NetBSD 2.99.10 (AURORA) #4: Fri Nov  5 19:44:52 MST 2004
which is GENERIC with viapm and viaenv enabled.

And detects as
Nov  5 19:57:02 aurora /netbsd: skc0 at pci0 dev 9 function 0: irq 10
Nov  5 19:57:02 aurora /netbsd: skc0: Marvell Yukon Lite Gigabit Ethernet rev. A3(0x7)
Nov  5 19:57:02 aurora /netbsd: sk0 at skc0 port A: Ethernet address 00:11:2f:75:bb:34
Nov  5 19:57:02 aurora /netbsd: makphy0 at sk0 phy 0: Marvell 88E1011 Gigabit PHY, rev. 5
Nov  5 19:57:02 aurora /netbsd: makphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto

Now a load test on fast ethernet gives
sftp> get archives.tar
archives.tar                                  100%  709MB   2.2MB/s   05:19    
sftp> bye
This is at 100/HD.  I can't run FD, but neither can the other boxen on
the network - I think it's the hub.

No hangs!  Also, I did not have to define SK_DEBUG as reported earlier
on this list.

For comparison, I checked the same transfer from the same (linux) server
to a linux client on the same network and got
sftp> get archives.tar
Fetching /tmp/archives.tar to archives.tar
/tmp/archives.tar                             100%  710MB   1.6MB/s   07:21    
sftp> 

It works for me and now I'm a happy camper.  BTW, this is a really nice
MB and everything else works fine as far as I can tell (but I haven't
checked out sensors yet).

-- 
Steve Bowman
Buckeye, AZ

Powered by Debian GNU/Linux, GNU/Hurd <http://www.debian.org/>,
           and NetBSD <http://www.netbsd.org>