00:13:40 The bug tracker should be back online now. We apologise for the inconvenience. 00:17:03 thanks jclulow. I was wrapping up for the day but I guess as my last work-related act for the year I'll submit this bug report. 00:17:15 Thanks! 00:17:24 bugs always welcome! 00:22:02 https://www.illumos.org/issues/17010 00:22:03 → BUG 17010: tar has issues with large files with SMB permissions when given the 'p' flag (New) 00:22:51 I hope the report gives sufficient information. 00:23:33 and with that I'll wish everyone a Happy New Year and wander off to play a video game or something. 17:54:10 Could someone eli5 the difference between EN and ADV mac properties (I read the comment in mac.h and it's not enough for me). I feel like I'm missing the difference here - if I configure the prop for autoneg (EN), that's something that should be exposed over wire (ADV)? 18:13:09 see mac(9e): " A user can control what speeds a device advertises via auto-negotiation 18:13:09 and whether or not it performs auto-negotiation at all by using a series 18:13:09 of properties that have _EN_ in the name. These are read/write 18:13:09 properties and there is one for each speed supported in the operating 18:13:09 system." 18:13:29 " In addition to these properties, there is a corresponding set of 18:13:29 properties with _ADV_ in the name. These are similar to the _EN_ family 18:13:29 of properties, but they are read-only and indicate what the device has 18:13:29 actually negotiated. While they are generally similar to the _EN_ family 18:13:29 of properties, they may change depending on power settings." 18:14:26 so: _EN_ is set by the sysadmin. _ADV_ is set by the driver to indicate what it's actually doing on the link (based in part on what is set in _EN_, what the peer advertised via autoneg, and what the hardware is actually capable of at the moment) 18:15:26 so the ADV name is misleading and it's actually should be NEG? 18:17:22 that's one way of looking at it, yes. I think it started (when the menu was smaller) as "what the peer advertised to us" 18:18:19 ok, so without using some proprietary extensions, there's only one ADV that needs to reported as 1? 18:18:52 what we agreed on with the peer 18:20:58 for speed/duplex, only one. but there's also MAC_PROP_{EN,ADV}_FEC_CAP and other orthogonal properties could surface in the future. 18:21:15 yeah, I mean speed/duplex here, thanks 18:23:51 see the Link Speed and Auto-negotiation section of mac(9e) 18:24:28 yeah, I read that, just needed a bit of confirmation that I'm understanding it correctly 18:33:04 yuripv: hmm, looking at dladm show-linkprop and dladm show-ether -x, it would appear that I'm wrong - the "adv" shows the intersection of peer capabability and our capability, so more than one adv cap for speed/duplex can be 1 18:35:08 how do we know the peer capability though? 18:35:41 I see the some broadcom extension with bnxt, but it's not generally available? 18:36:00 presumably it's what the peer is advertising through ethernet autonegotiation 18:36:35 (so it's not the full suite that it's capable of, just what it's admitting it can do at the moment) 18:38:07 well, my understanding was we tell our h/w "we can do this" and peer tells their h/w "we can do this" and h/w does autoneg without involving the s/w :D 18:38:51 yeah, but local h/w will also generally provide a way to report back what the peer offered as well as what they agreed on. 18:44:26 looks like it's even more interesting looking at the ETHER_STAT, there's EN (enabled), ADV (being advertised), LP (supported by peer) 18:45:03 err, s/EN//, just supporting the speed/duplex