The bug tracker should be back online now. We apologise for the inconvenience.

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.

Thanks!

bugs always welcome!

→ BUG 17010: tar has issues with large files with SMB permissions when given the 'p' flag (New)

I hope the report gives sufficient information.

and with that I'll wish everyone a Happy New Year and wander off to play a video game or something.

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)?

see mac(9e): " A user can control what speeds a device advertises via auto-negotiation

and whether or not it performs auto-negotiation at all by using a series

of properties that have _EN_ in the name. These are read/write

properties and there is one for each speed supported in the operating

system."

" In addition to these properties, there is a corresponding set of

properties with _ADV_ in the name. These are similar to the _EN_ family

of properties, but they are read-only and indicate what the device has

actually negotiated. While they are generally similar to the _EN_ family

of properties, they may change depending on power settings."

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)

so the ADV name is misleading and it's actually should be NEG?

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"

ok, so without using some proprietary extensions, there's only one ADV that needs to reported as 1?

what we agreed on with the peer

for speed/duplex, only one. but there's also MAC_PROP_{EN,ADV}_FEC_CAP and other orthogonal properties could surface in the future.

yeah, I mean speed/duplex here, thanks

see the Link Speed and Auto-negotiation section of mac(9e)

yeah, I read that, just needed a bit of confirmation that I'm understanding it correctly

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

how do we know the peer capability though?

I see the some broadcom extension with bnxt, but it's not generally available?

presumably it's what the peer is advertising through ethernet autonegotiation

(so it's not the full suite that it's capable of, just what it's admitting it can do at the moment)

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

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.

looks like it's even more interesting looking at the ETHER_STAT, there's EN (enabled), ADV (being advertised), LP (supported by peer)

err, s/EN//, just supporting the speed/duplex