- User Since
- Mar 18 2016, 8:59 PM (104 w, 23 h)
Thu, Mar 8
Wed, Mar 7
Hans, did you ever get a chance to test this?
Tue, Mar 6
This worked on older versions of our product, which were based roughly on FreeBSD 7.x
Fri, Feb 16
Feb 15 2018
Feb 8 2018
Jan 26 2018
Thanks for this. I've noticed this behavior when debugging an unrelated ND6 issue, but never dug into where it happens in the code.
Jan 25 2018
Jan 18 2018
Nov 9 2017
First off, please submit future patches with arc diff directly, or with a diff generated with full context.
Nov 3 2017
- in order to be MFCable we can't change the eventhandler_list layout.
Nov 1 2017
- style fixups.
- manpage style and extraneous use of "relative"
- remove the flags field as it is not needed.
- style nit
- use a pointer as the global reference to the pre-defined list, allowing for these lists to be created on-register (e.g. from a module) before they are defined. This was the approach suggested and taken by ian in his revision.
- refactor API usage to reflect this change. LISTS are now defined and declared separately from the eventhandlers. The corresponding invoke is EVENTHANDLER_DIRECT_INVOKE since I think EVENTHANDLER_LIST_INVOKE is too confusing (whereas DIRECT can reasonably imply direct disaptch-ish semantics).
- Now you must use EVENTHANDLER_LIST_DEFINE to create the reference to the list. EVENTHANDLER_LIST_DECLARE is only needed to declare the list pointer extern, so for callers of EVENTHANDLER_DIRECT_INVOKE that are not in the same compilation unit as the DEFINE.
- small change to make the eventhandler list name stored at the end of the struct, since the storage is always allocated at the end of the struct anyway.
- remove EHL_INITTED since it is no longer a relevant state (the lists are initialized either by the SYSINIT stage for eventhandler or when the first handler is registered).
- update EVENTHANDLER(9) to reflect the API addition, with the recommendation to use the EVENTHANDLER_LIST/DIRECT macros.
Oct 31 2017
Oct 30 2017
Oct 28 2017
Oct 23 2017
Oct 22 2017
I'd rather not turn my (perhaps radical) parentheses opinions into a bikeshed. At the least I request not adding new ones that aren't needed, but if kib or someone else prefers they stay I won't get in the way.
The superfluous parentheses stuff is sort of nitpicky, but I do feel that at least in the case where the expansion is surrounded by commas then it should be dropped since comma operators / separators have the lowest possible precedence.
Oct 20 2017
Oct 19 2017
Oct 16 2017
Oct 14 2017
- Might as well use TAILQ_FOREACH_SAFE while we are here.
Oct 13 2017
- use init_unrhdr instead of duplicating it
Oct 11 2017
Oct 4 2017
- Add comment explaining the conditional free_unr
- Fixup manpage.
- Move KASSERT.
Sep 16 2017
Sep 13 2017
Sep 12 2017
For anyone wondering about the history here, see this thread from -net: https://lists.freebsd.org/pipermail/freebsd-net/2017-August/048621.html. TL;DR is this: https://lists.freebsd.org/pipermail/freebsd-net/2017-September/048826.html
Sep 5 2017
That's true, but what's so offensive about having another module? Why do we need to wait for abundant reasons to have logical code separation as opposed to copy paste code sharing?
Sep 4 2017
Sep 2 2017
My thought is that this is outside the scope of this revision since it's an existing problem in amdtemp. It's not totally clear to me what the best way to do it since the different parts have different offsets, but it's something someone should probably explore. If we can reliably map the offsets for every known part in every generation it would be a nice convenience feature.
Also missing the sys/modules/amdsmn directory, so doesn't work with buildkernel at the moment.
Aug 31 2017
Upon further inspection, it doesn't actually matter for bridge interfaces.
When you commit can you be more explicit about why this fixes it with the extended media types? For people not familiar with if_lagg some more specifics in the message would be helpful.
Aug 24 2017
The integer handling looks correct. It is definitely better than the defined-but-bad behavior of truncating the non-fractional bits of sbintime_t on ILP32. Using unsigned values everywhere makes all the operations well-defined and reasonable.
Aug 23 2017
Aug 22 2017
Aug 20 2017
mjoras@icarium ~> sysctl hw.model hw.model: AMD Ryzen Threadripper 1950X 16-Core Processor
So I will note that on my system hwpstate ends up opting to get these from acpi_perf:
kernel: hwpstate0: going to fetch info from acpi_perf ... mjoras@icarium ~> sysctl dev.hwpstate.0.freq_settings dev.hwpstate.0.freq_settings: 3400/3825 2800/2765 2200/1952
Aug 16 2017
Aug 15 2017
Aug 4 2017
Aug 3 2017
Aug 2 2017
- add per-ring sysctl for defrag_attempts
Aug 1 2017
Here's an older test output that shows defrag_attempts and oversized_packets:
durinf004-1: hw.mlxen1.stat.tx_oversized_packets: 0 durinf004-1: hw.mlxen1.stat.defrag_attempts: 117 durinf004-2: hw.mlxen1.stat.tx_oversized_packets: 0 durinf004-2: hw.mlxen1.stat.defrag_attempts: 1 Fri Jul 21 18:46:25 PDT 2017 durinf004-1: hw.mlxen1.stat.tx_oversized_packets: 0 durinf004-1: hw.mlxen1.stat.defrag_attempts: 121 durinf004-2: hw.mlxen1.stat.tx_oversized_packets: 0 durinf004-2: hw.mlxen1.stat.defrag_attempts: 1 durinf004-1# tail -n 10 logfile Sun Jul 23 23:00:25 PDT 2017 durinf004-1: hw.mlxen1.stat.tx_oversized_packets: 0 durinf004-1: hw.mlxen1.stat.defrag_attempts: 9306 durinf004-2: hw.mlxen1.stat.tx_oversized_packets: 0 durinf004-2: hw.mlxen1.stat.defrag_attempts: 47 Sun Jul 23 23:00:55 PDT 2017 durinf004-1: hw.mlxen1.stat.tx_oversized_packets: 0 durinf004-1: hw.mlxen1.stat.defrag_attempts: 9306 durinf004-2: hw.mlxen1.stat.tx_oversized_packets: 0 durinf004-2: hw.mlxen1.stat.defrag_attempts: 47