Mac Mini - tg3 driver issues

[lumps]

Below are the driver tests for two Apple NICs:

A. Builtin Mac Mini NIC [14e4-1686] unsupported (no entry in tg3.c table)
B. Thunderbolt Ethernet dongle [14e4-1682] supported (in table)

Happy to do more tests based on suggestions observations.
--------------------------- snip ------------------

Client Hardware
===============

"Late 2012 Mac Mini - OSX 10.9.3"

Port A: built in ethernet - PCI 14e4-686
Port B: Thurderbolt Ethernet dongle - PCI 14e4-1682

Server Hardware
===============
MacBookPro 2013 - OSX 10.9.3
. (Port D): Thunderbolt Ethernet (10.5.5.2)

VMWare Fusion - CentOS 6.4
. Port C: Thunderbolt Ethernet dongle (10.5.5.1)

Software Setup
==============
ipxe - 0e3ab6064e9f9eec28712c3b2c1e082672e73461 (git://git.ipxe.org/ipxe.git)
. added Port A with a PCI_ROM() entry

rEFIt - boot

ISC DHCP 4.1.1
. simple setup: subnet 10.5.5.0 netmosk 255.255.255.0 { range 10.5.5.20 10.5.5.30; }

Wireshark 1.8.10

python -mSimpleHTTPServer (for load tests)

A Driver Tests
==============
All tests are performod with either Port A or B connected to Port C.

Link detection
. no link detection with PCI_ROM() entry - see note in Hardware, above
. reports Link:up with cable plugged in
. reports Link:down upon disconnect
. repeated connects/disconnects report proper Link state
Basic DHCP
. link-up: ok
. configure: Error 0x0ee186
. ifstat: [Link:up TX:8 TXE:0 RX:0 RXE:0]
. tshark -i eth0 '(ether src <MAC A>) || (ether dst <MAC A>)' - shows no activity
!! do deeper dive into data transmission issues
Close and reopen
Large file transfer correctness
Large file transfer speed
Link interruption
Loopback
High-MTU loopback
VLAN loopback

B Driver Tests
==============
Link detection
. reports Link:up with cable plugged in
. reports Link:down upon disconnect
. repeated connects/disconnects report proper Link state
Basic DHCP*
. link-up: ok
. configure: Error 0x0ee186
. route: 10.5.5.21/255.255.255.0
. can ifopen/dhcp/ifclose multiple times
* 'dhcp' only acquires an address if I first bring the link up via 'ifopen net1',
wait for the link to come up via 'ifstat', then run 'dhcp'.
* DHCP Discover comes much sooner in the "Configuring...." process when using the
steps above vs. just running 'dhcp' which doesn't show DHCP Discover towards
the end of the ollated time (this may just be a figment of tshark, not sure.)
Close and reopen
. can ifopen/dhcp/ifclose multiple times
Large file transfer correctness
. md5sum: ok
. sha1sum: ok
Large file transfer speed
. roughly 12 seconds
Link interruption
. link recovers from multiple interruptions
Loopback
. can't perform this test because Port A won't configure
High-MTU loopback
. same
VLAN loopback
. same

2014-06-26

[robinsmidsrod]

Great that you have taken the time to perform these tests. It seems like the Thunderbolt adapter is close to working, it might just be a timer issue, and it just needs slightly more time during (some) init phase to avoid the error. I've pinged some of the developers on IRC to have a look at this page. Hopefully they'll respond with some insightful comments.