Well things aren't looking so good for the sk(4) driver on the ES40
either.  We managed to source a D-Link Systems DGE-530T card to test as
well, and it is at least recognized:

[console]<@> # dmesg | fgrep -e skc0 -e makphy0
skc0 at pci1 dev 1 function 0: dec 6600 irq 24
skc0: DGE-530T Gigabit Ethernet Adapter rev. (0x1)
sk0 at skc0 port A: Ethernet address 00:0f:3d:88:13:3d
makphy0 at sk0 phy 0: Marvell 88E1011 Gigabit PHY, rev. 3
makphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto



I didn't know which wire they'd plugged into it so of course I picked
the wrong subnet first or at least that's what I thought given what I
initially observed

[console]<@> # ifconfig sk0 inet 10.10.10.2/24 up
[console]<@> # ping 10.10.10.1
PING 10.10.10.1 (10.10.10.1): 48 data bytes
ping: sendto: Host is down
ping: sendto: Host is down
^C
----10.10.10.1 PING Statistics----
13 packets transmitted, 0 packets received, 100.0% packet loss



But then when I tried to change the address it barfed completely:

[console]<@> # ifconfig sk0 10.10.10.2 delete     
[console]<@> # ifconfig sk0 inet 10.20.20.2/24 up
sk0: failed alloc of 0th mbuf
sk0: initialization failed: no memory for rx buffers
sk0: failed alloc of 0th mbuf
sk0: initialization failed: no memory for rx buffers
sk0: failed alloc of 0th mbuf
sk0: initialization failed: no memory for rx buffers
stray isa irq 4
ifconfig: SIOCAIFADDR: No buffer space available
[console]<@> # ifconfig sk0       
sk0: flags=8803<UP,BROADCAST,SIMPLEX,MULTICAST> mtu 1500
        address: 00:0f:3d:88:13:3d
        media: Ethernet autoselect (1000baseT full-duplex)
        status: active
[console]<@> # ifconfig sk0 inet 10.20.20.2/24 up
sk0: failed alloc of 0th mbuf
sk0: initialization failed: no memory for rx buffers
sk0: failed alloc of 0th mbuf
sk0: initialization failed: no memory for rx buffers
sk0: failed alloc of 0th mbuf
sk0: initialization failed: no memory for rx buffers
ifconfig: SIOCAIFADDR: No buffer space available
[console]<@> # 


Turns out I was right about which subnet it was on in the first place.
The card can receive packets OK, at least in promiscuous mode, but it
never transmits anything that I can see at the test host on the other
side of the switch.


[console]<@> # tcpdump -vvv -n -e -i sk0
tcpdump: listening on sk0
13:00:07.430668 0:1:f4:b2:66:a5 1:80:c2:0:0:0 0027 60: 802.1d unknown version
13:00:09.431613 0:1:f4:b2:66:a5 1:80:c2:0:0:0 0027 60: 802.1d unknown version
13:00:11.432657 0:1:f4:b2:66:a5 1:80:c2:0:0:0 0027 60: 802.1d unknown version
13:00:12.764840 0:1:f4:b2:66:a5 1:80:c2:0:0:21 002e 60: 802.1d unknown version
13:00:12.964909 0:1:f4:b2:66:a5 1:80:c2:0:0:21 002e 60: 802.1d unknown version
13:00:13.433630 0:1:f4:b2:66:a5 1:80:c2:0:0:0 0027 60: 802.1d unknown version
13:00:13.747422 0:e:c:5a:ee:b2 ff:ff:ff:ff:ff:ff 0800 98: 10.10.10.1 > 10.10.10.255: icmp: echo request (ttl 64, id 6176, len 84)
13:00:14.747912 0:e:c:5a:ee:b2 ff:ff:ff:ff:ff:ff 0800 98: 10.10.10.1 > 10.10.10.255: icmp: echo request (ttl 64, id 6178, len 84)
13:00:15.434679 0:1:f4:b2:66:a5 1:80:c2:0:0:0 0027 60: 802.1d unknown version
13:00:15.748677 0:e:c:5a:ee:b2 ff:ff:ff:ff:ff:ff 0800 98: 10.10.10.1 > 10.10.10.255: icmp: echo request (ttl 64, id 6179, len 84)
13:00:16.749512 0:e:c:5a:ee:b2 ff:ff:ff:ff:ff:ff 0800 98: 10.10.10.1 > 10.10.10.255: icmp: echo request (ttl 64, id 6180, len 84)
13:00:17.435652 0:1:f4:b2:66:a5 1:80:c2:0:0:0 0027 60: 802.1d unknown version
13:00:17.750342 0:e:c:5a:ee:b2 ff:ff:ff:ff:ff:ff 0800 98: 10.10.10.1 > 10.10.10.255: icmp: echo request (ttl 64, id 6181, len 84)
13:00:18.751109 0:e:c:5a:ee:b2 ff:ff:ff:ff:ff:ff 0800 98: 10.10.10.1 > 10.10.10.255: icmp: echo request (ttl 64, id 6182, len 84)
13:00:19.436696 0:1:f4:b2:66:a5 1:80:c2:0:0:0 0027 60: 802.1d unknown version
13:00:19.751940 0:e:c:5a:ee:b2 ff:ff:ff:ff:ff:ff 0800 98: 10.10.10.1 > 10.10.10.255: icmp: echo request (ttl 64, id 6183, len 84)
13:00:21.437673 0:1:f4:b2:66:a5 1:80:c2:0:0:0 0027 60: 802.1d unknown version
^C
17 packets received by filter
0 packets dropped by kernel


The counters do seem to claim that one packet was transmitted:

[console]<@> # netstat -in
Name  Mtu   Network       Address              Ipkts Ierrs    Opkts Oerrs Colls
tlp0* 1500  <Link>        08:00:2b:c4:b5:26        0     0        0     0     0
sk0   1500  <Link>        00:0f:3d:88:13:3d       17     0        1     0     0
sk0   1500  10.10.10/24   10.10.10.2              17     0        1     0     0
wm0*  1500  <Link>        00:0e:0c:5a:ee:9d        0     0        0     0     0
tlp1* 1500  <Link>        08:00:2b:c4:7a:70        0     0        0     0     0
bge0* 1500  <Link>        00:08:02:91:89:ae        0     0        0     0     0
lo0*  33136 <Link>                                 8     0        8     0     0


Perhaps it's still sitting in a buffer and not going anywhere....



-- 
						Greg A. Woods

+1 416 218-0098                  VE3TCP            RoboHack <woods@robohack.ca>
Planix, Inc. <woods@planix.com>          Secrets of the Weird <woods@weird.com>