00:00:49 got a strange situation where that's trying to unload an instance of a NIC that's a part of a link aggregation, while at the same time, dladm is trying to create a vnic over that aggr 13:16:09 @andyf https://code.illumos.org/c/illumos-gate/+/2665 bit late as I was busy the weekends after FOSDEM 13:16:10 → CODE REVIEW 2665: 15271 document viona tunable to force copy of tx buffers (NEW) | https://www.illumos.org/issues/15271 13:16:35 Also there is no special build artifact for the manpage? It just the same file ? 13:32:12 Yes it's the same file. I'll take a look, thanks! 15:02:19 sjorge, andyf: Is this intended to be a permanent thing? 15:02:36 Or is this tunable only one that's going to exist as long as a workaround is required? 15:21:37 I think the `viona_force_copy_state` will persist. It is something which is normally turned on if the bnxe driver is loaded, for unknown reasons. 15:24:46 I don't know if anyone has ideas on illumos 13463 (fenix) 15:24:51 BUG 13463: bhyve locks up when viona ring buffers on loan to a local zone are not returned by sockfs (New) 15:24:51 ↳ https://www.illumos.org/issues/13463 15:26:32 There's still the question of whether setting a boolean_t from /etc/system is something technically allowed too. I didn't see an answer to sjorge's question on that, but I have seen other recent changes where the author deliberately used an 'int' for a tunable. 15:27:01 I think it's fine, given what the compiler generates, but it is not covered by the text of system(5) 15:59:26 heh.. device tree issues seem to be the theme today :) 16:03:51 well technically this appears to be more of a deadlock involving aggr, mac, and dls/softmac 16:04:28 just that it causes things to be held in the device tree... making life difficult for other things 16:30:28 should dld depend on softmac since it's making calls directly to it? 16:31:52 (right now I see a call through stubs_common_code between drv_ioc_phys_attr()->softmac_hold_device() 18:45:56 rmustacc like andyf said, ideally the actual bug gets fixed but thats is certainly beyond my skill set. I originally added a new variable (a boolean_t) to set this but as suggested by andy I abandoned that one as we can set the viona:viona_force_copy_state enum which already exists to 2, as in both cases of boolean_t and enum we're really just settings integers. 18:46:48 This cr just documents you can do this as a workaround if you're hitting the problem. (For my use case I say now change in performance, well it increased actually as now congestion control can do it's job instead of the connection just stalling from the lack of ability for the VM top send out acks. 18:50:05 So far I had 0 issues (related to this) since forcing copy on TX 18:51:17 I hit one in guest cifs issue but I've seen it at work too using vmware+redhat so I don't think bhyve was involved in anyway, I have since moved that mount to nfs too (which was the original idea anyway) and not had any issues at all since then, and performance is like 10-20x of what I was getting over cifs so win win win there :) 18:55:49 sjorge: Just was asking to figure out if we needed to promise that this would always be a tunable or not. 20:15:59 i need to try to code it up, but how much interest would there be in a flag to ::findstack that'd include the type of the function argument in the output besides just the argument value? (IIRC, CTF should have this information) 20:16:24 i know you can also do source spelunking, but seems like it could be handle while drilling down to avoid having to switch back and forth as much 20:16:32 err be handy 20:17:12 has the info, sounds nice 20:17:29 It would! I often use `::nm -f ctype` and this sounds like less effort 20:17:50 I keep hoping I can convince someone to wire gdb's @entry stuff up to saveargs too, if you want a different kind of fun :) 20:18:23 i'm unfamiliar with that... and it sounds like i'm better for it :) 20:36:25 I'd been meaning to implement something like that jbk. 20:36:38 So in general, I think it'd be good. 21:43:50 does ctf record formal argument names too? 22:07:45 [illumos-gate] 15395 ndi_devi_enter deadlock: di_copytree et al vs hotplug -- Dan Cross