01:24:27 richlowe: anything specific? 01:24:35 we build our fork w/ libressl 01:26:07 but i'm not sure offhand what was involved (e.g. just ignore/nuke bits we don't use that delve into openssl internals) 01:26:34 though we also do have a number of patches applied as well 01:28:50 well they exist.. i'm not sure looking at them that they'd be relevant at all 09:49:06 pmooney: one of my 2 nodes is broadwel 09:50:03 E5-2680 v4 10:29:36 hi all, i see we have removed 'bus_mps' from pcie_impl.h and some code, but i see comments with it at many places . will be better to remove all references about 'bus_mps' 11:00:56 Sounds good, no objection here. 14:18:38 For those following along outside the joined/left spam... Here's t he Broadwell MSR info for pmooney 14:18:39 0x48c: 0xf0106334141 14:18:46 (Same as my Haswell sample(s). 15:35:44 is there any go lib for listening to illumos system events? 15:39:29 i don't think so 15:39:37 but be careful 15:39:53 ./just-got-very-scared 15:40:12 I saw https://github.com/tritondatacenter/node-sysevent 15:40:36 Was hoping to create a counter for when physical interfaces change their link state 15:40:46 IIRC the sysevent client library starts a door server to recieve events 15:41:01 not sure if that's already available in kstat 15:41:21 and if you fork() at the wrong time 15:41:39 you hit a deadlock, and your process is unkillable 15:41:57 (it's a really thorny problem, so it's easier to work around it) 15:46:27 ahhh ok, will go a different way lol 15:46:56 if you fork a helper before attaching to sysevents, that works around it 16:23:21 This is interesting, makes me want to setup a lab to test the optimization case with illumos https://youtu.be/36qZYL5RlgY 16:27:41 jbk if you have time, could you check over https://code.illumos.org/c/illumos-gate/+/2437? :) 16:27:42 → CODE REVIEW 2437: 15067 linker set should be declared WEAK (NEW) | https://www.illumos.org/issues/15067 16:47:19 thanks! 17:05:21 tsoome_: thanks for updating the tests on that linker-set work 17:05:45 it'll be nice to have that covered into the future 17:05:52 thanks for pointing to them, it is easy to forget about... 17:06:20 I've been trying to make it a habit of adding tests for new stuff 17:06:32 even if they are short or have incomplete coverage 17:06:36 something is better than nothing 17:07:36 tests which are using test-runner also benefit from tagging now, I have found it extremely useful with zfs tests 18:09:33 Smithx10: You could just configured syseventd tbh 18:09:55 see also syseventadm(8) 18:10:08 jclulow: ahhh ok 18:10:27 I believe you can just run any program in response to a particular sysevent 18:11:59 I'm really just interested in knowing how many times a physical link state changes 18:12:11 Think sysevent is the right facility for that? 18:13:45 I know that dmesg will log it, and maybe it would be better to just grok that ? 18:14:26 that would probably be better 18:15:39 So, I would poll a kstat first 18:15:44 if there is one 18:15:51 And if there is not, that seems like a good RFE 18:15:59 but syseventadm seems very reasonable otherwise 18:16:18 It's pretty much what it's there for 18:16:27 so you can do a thing in response to a system thing 18:59:28 [illumos-gate] 14957 pcieadm overloads header1.iobasehi -- Robert Mustacchi 19:50:25 `kstat -p ::mac:link_up` 20:04:00 if someone sends us an ICMP destination uncreachable message, do we actually do anything (e.g. route black hole)? 20:06:02 We percolate ENETUNREACH up to appropriate sockets if the inner packet has enough for us to match upon. 20:06:38 We may also rate-limit those because face it, some jackass could just spam you with 'em. 20:06:42 but that wouldn't impact _new_ sockets to the same IP, right? 20:06:56 Once traffic moves, and subject to the aforementioned rate-limiting. 20:07:15 (You'll have to get a fresh ICMP_DST_UNREACH for those new sockets.) 20:10:04 rzezeski: Thanks, but polling that every 15 seconds really doesn't help with measuring if its flapping 20:10:57 Think I might just inspect the kernel log for messages from within the prometheus scrape interval and bump the counts 20:12:25 If you're going to scrape at least scrape the ireport log so you can see the structured info. 20:14:41 rmustacc: ireport log ? not sure what that is 20:15:30 i suppose you could rig something up with dtrace as well -- just whenever mac_link_update() (or whatever it's called.. don't have it in front of me) is called.. 20:17:09 I mean, we could also add a kstat to count up/down events 20:17:31 that too :) 20:18:10 rzezeski: that would be the <3 20:18:34 and honestly, that seems like a reasonable thing to add as kstats are useful for knowing that some type of behavior has been happening without the need to log/dtrace the entire time 20:18:54 like "oh wow my link has flapped 7777 times since boot, that seems wrong" 20:21:17 we hacked together something, to find it happening throughout our fleet, but wanted to get it into grafana, currently we just use the cmon plugins (https://github.com/TritonDataCenter/triton-cmon-agent/tree/master/docs#plugins). The Grok makes more sense for the scrape interval because I dont want to add another daemon... But a kstat would make this simpler 20:22:10 network folk / dc team gets a nice email now 20:23:08 Smithx10: okay well unless rmustacc knows of something that exists for this or has some objection I think it's worth adding an illumos issue, should be easy enough for any of us to pick up (lol anytime I say something is easy it turns out cursed) 21:09:10 seeing the following when building bhyve-tests: https://pastebin.com/FqzZiXw7, is it just me? 21:11:38 hmm, pushed on Oct 2, must be something local; could it be related to binutils being 2.25? 21:39:33 sounds possible