06:50:41 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 06:50:41 higher value there. 15:12:35 jbk, would you like me to report ICE status here or in /msg? 15:17:50 here is fine unless it's going to be a lot of text, then might be better to msg it 15:18:37 (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 15:22:32 (the branch is up at https://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 15:23:16 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) 15:23:27 but nothing that should impact functionality 15:27:19 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. 15:27:29 on reboot, four lines saying ""WARMING: ice0: get link status (disable) command failed with: Invalid argument 15:27:29 (EINVAL - 14) (fw private: 0)" 15:27:48 (ignore that errant after 'arugment' - they were all one line.) 15:30:05 hrm.. is anything plugged in to that port? 15:30:06 post-reboot, neither dladm nor ipadm show ice devices. 15:30:15 sounds like it failed to attach 15:30:20 yes, there is a cable plugged into both ice0 and ice1. 15:30:42 (the one that goes back to the single port on our Juniper switch)