about mtu setup - it appeares the dhcpagent is setting it via SIOCSLIFMTU in ip layer, which in turn is limited by ill_max_frag which is set for vioif during its setup based on current (default) mtu (macp->m_max_sdu = vif->vif_mtu; in vioif.c) and therefore blocks SIOCSLIFMTU to set anything above its current MTU. dladm appears to get to call vioif_m_setprop() which does update interface mtu and will therefore allow us to get to use

higher value there.

jbk, would you like me to report ICE status here or in /msg?

here is fine unless it's going to be a lot of text, then might be better to msg it

(btw, i don't know if anyone else has access to the hw and wants to test, please let me know... i'd obviously like to get as much testing as I can

(the branch is up at github.com/jasonbking/illumos-gate/tree/ice-dev and rebased against a very recent illumos-gate (past couple of days) and squashed down if anyone wants to build it themselves

there is a little bit of cleanup I still want to do (ported some bits that turned out to not be needed, and there's probably a few XXX or TODO comments that need updating or removal now)

but nothing that should impact functionality

you were right about needing 'ice' at the end of the command. I am guessing that was the new BE name, as it created a be named ice as part of the pkg command.

on reboot, four lines saying ""WARMING: ice0: get link status (disable) command failed with: Invalid argument

(EINVAL - 14) (fw private: 0)"

(ignore that errant <CR> after 'arugment' - they were all one line.)

hrm.. is anything plugged in to that port?

post-reboot, neither dladm nor ipadm show ice devices.

sounds like it failed to attach

yes, there is a cable plugged into both ice0 and ice1.

(the one that goes back to the single port on our Juniper switch)