05:00:50 <gitomat> [illumos-gate] 16319 tools: add yacc to build tools -- Toomas Soome <tsoome⊙mc>
05:15:55 <yuripv> rmustacc: is MAC_CAPAB_RINGS an illumos addition or does it predate it?
05:41:56 <richlowe> predates it
05:42:07 <yuripv> thanks!
06:15:25 <yuripv> https://www.illumos.org/issues/16608
06:15:26 <fenix> → SUPPORT 16608: ZOLA (New)
06:15:38 <yuripv> some spam over there
07:51:05 <gitomat> [illumos-gate] 16612 libshare does not build with libxml2 2.13 -- Andy Fiddaman <illumos⊙fn>
13:22:36 <rmustacc> yuripv: We have made some changes since then and similarly, Oracle has too.
13:34:53 <yuripv> rmustacc: thanks, i was also wondering if this check makes any sense: https://src.illumos.org/source/xref/illumos-gate/usr/src/uts/common/io/mac/mac_provider.c?r=86e5bb79#414, documentation does not seem to tell anything about *requiring* RX rings?
13:36:28 <rmustacc> Probably because I left it out of the docs accidentally?
13:36:44 <rmustacc> I wrote all those manuals at some point in an attempt.
13:36:54 <yuripv> also the documentation does not seem to mention that mac->m_v12n = MAC_VIRT_LEVEL1; is required as well, got few happy panics trying to use mc_tx callback :)
13:36:55 <rmustacc> I think if you don't have rx rings, then there's not much point tbh.
13:37:12 <rmustacc> I would not be surprised there's some bugs there.
13:37:13 <rmustacc> Sorry.
13:37:15 <yuripv> probably, just wanted to implement tx stuff first
13:37:59 <rmustacc> Makes sense. But I probably would keep the check unfortunately.
13:39:36 <rmustacc> Make notes of issues you find missing in the docs and I can take a pass through that. I suspect there may be some other issues that I remember Jason filing.
13:40:25 <rmustacc> Ah, yeah. He filed https://www.illumos.org/issues/15061 which I missed.
13:40:26 <fenix> → BUG 15061: mac_capab_rings(9E) missing discussion of MAC_VIRT_LEVEL1 (New)
13:40:37 <yuripv> oops, didn't check
13:41:27 <rmustacc> All good. There are probably some others.
13:41:34 <rmustacc> Not on you to check it.
16:03:19 <sjorge> our bhyve only does 9p right? not virtfs?
16:03:36 <sjorge> Seems they are different things but internet seems to mix them up sometimes.
16:09:13 <sjorge> Seems we indeed only support 9p not the more performant virtfs
16:09:41 <sjorge> Well it's not a we thing, it's a bhyve thing in general
16:14:30 <jclulow> sjorge: From what I recall, the newer virtfs thing is, on some level, the relatively raw tunneling of Linux VFS operations out of the guest into the host
16:14:53 <jclulow> Which is probably a pain to implement :P
16:16:02 <sjorge> Smells like the same old trap of people thinking linux == posix
16:16:10 <sjorge> If that is indeed the case it sounds like a pain in deed
16:17:07 <rmustacc> No one really has the same vfs, unless you forked and haven't changed it.
16:21:11 <sjorge> I'm guessing that is also why FUSE on anything not linux is kind of a pain
22:04:06 <gitomat> [illumos-gate] 16573 smntemp Tctl is not degrees C -- Robert Mustacchi <rm⊙fo>
22:14:52 <mjg> i'm running fresh omnios (omnios-r151046-8ab991ea831) and can reliably crash mdb with signal delivery
22:15:14 <mjg> 1. spawn mdb 2. pkill -1 mdb
22:15:19 <mjg> > zsh: segmentation fault (core dumped)  mdb
22:15:47 <mjg> crash backtrace https://dpaste.com/7BFM9G9B3
22:15:57 <mjg> i'm not sending it random crap, i am resizing a window and it crashes
22:16:18 <mjg> (presumably SIGWNCH or whatever the name)
22:16:27 <mjg> and with that i'm going afk, cheers
22:17:02 <rmustacc> Thanks for reporting that, we'll look into it. I got a slightly different stack trace, but either way, not good. Sorry for the trouble.
22:18:46 <mjg> i'll live
22:18:46 <mjg> ;)