00:38:05 [illumos-gate] 15220 isatty should return reasonable errnos -- Robert Mustacchi 09:14:35 has anyone tried to raise MAXPATHLEN? 10:33:54 well that was weird. dragon friend's VM just spinlocked for two hours. zero disk, zero network, 100% cpu. I couldn't make it panic because I had no kind of access. 10:34:07 so I couldn't get a core dump. 10:35:35 I wonder what I should look for in logs, starting around 8am UTC or maybe a bit before 10:35:44 7am 10:35:46 three hours, gosh. 13:43:27 Interesting read rmustacc for IPD 38, although a lot of it goes way over my head. 15:51:05 So I've been looking around the viona doe a bit, woud a /etc/system tunable just need to force https://github.com/illumos/illumos-gate/blob/aa88555e2aa3d01aff5e421451572bdfcf722282/usr/src/uts/intel/io/viona/viona_tx.c#L100 to always return true to be effective? 15:51:15 s/doe/code/ 16:08:37 I guess in theory this should do it right? https://github.com/omniosorg/illumos-omnios/compare/master...sjorge:illumos-omnios:viona_force_copy?expand=1 16:08:59 I'll try and figure out how to compile that when I am less sick. 18:27:58 sjorge: i think so (though testing is always better than guessing)... 18:28:36 the one thing that might be a concern from what I recall is it may prevent the VM front getting stuck 18:29:11 but it looked like we're somehow not triggering a notification on the read size (when the destination is a local non-VM zone) 18:30:03 like the one core had like several MB of data ready for the zone, the process was blocked in either poll() or port_get(), but data wasn't moving 18:30:21 if my recollection is correct, that may not address that aspect 18:30:34 (which might be fine for you uses, just pointing that bit out) 18:44:32 building omnios now, not sure how to get it on my actual hw though 18:45:12 and yeah it doesn't fix the issue of the local non-VM zone 18:45:22 but it should prevent the bhyve hangs 18:45:24 i think 18:46:22 build gonna take a while though 18:46:38 thats step 1 😅 19:07:19 Well failing on that, given kvm doesn't seem to compile :/ 19:07:35 Not that I need kvm, but just following the omnios build instructions at this point 19:08:30 Oh I'm dumb, I think I know where I went wrong, off for another few hour wait 19:15:47 FWIW I hit this yesterday 19:16:15 The reproduction is completely reliable: I was using rsync to try and copy a 2GB file from inside an OmniOS VM (bhyve, SmartOS host) to the host GZ 19:16:47 As soon as it kicks up to line speed on outbound data transfer, the window expands to the point where it fills the 256 ring entries and then it corks 19:17:19 I don't think it's a missed poll wakeup at all, I think the rsync on the GZ side stops reading data because it's trying to send acks/hashes back to the guest and it's basically a classic pipe deadlock situation 19:17:45 If I made the vqsize vastly bigger I am sure it would happen less, or at least happen later, as sjorge has noted 19:18:12 that could be -- all i could see was the reading process stuck in one of those despite the conn_t showing multiple MB of data queued 19:18:24 from the dump at the time 19:18:57 I'm pretty sure in this case the rsync is waiting to write before it gets around to reading again 19:19:34 We're only going to send 256 * 1500 bytes in this configuration before we get corked 19:19:37 which is _tiny_ 19:38:47 Yes, lowering vqsize from the default is a speedrun any% to get it for me 19:39:02 Glad someone was able to reproduce it reliably aside from me now 19:45:01 I'm surprised I haven't hit this myself. I have a wireguard bhyve VM and I have used to to talk to local native zones 19:51:09 So... how much space is needed to build omnios? 50G is apparently not enoug has I wrecked the vm when it went out of disk space :/ 19:53:57 build... all of omnios? 19:54:10 probably better for #omnios, but I'm also not sure why you'd do that. 19:54:50 Well i just ran omni build_illumos 19:55:04 so I would expect that to just be illumos-gate, well illumos-omnios I guess 19:55:20 yeah, definitely an answer I don't know, but for building illumos "Not that much" 19:55:41 rpool/builds/richlowe/illumos-git referenced 7.70G - 19:57:11 (that has a bunch of extra crap in it, so less than that much) 19:57:47 OK, gonna retry tomorrow and not run it in vmware fusion on my laptop 20:06:00 you might ask hadfl or andyf just to find out what it's going to do 20:06:09 maybe it'll build all the dependencies or something, but even that shouldn't be _that_ big 20:08:09 sjorge: Maybe make sure you have compression enabled on the pool 20:23:27 tsoome: i_dladm_flow_proplist_extract_one() alone is really bugging me for reasons that have nothing to do with your reasonable initialize-a-local fix. 20:24:21 Oh compression was probably not on 20:27:32 Gonna be smarter this time and set a quota on my build dataset so it doesn't cause havoc if it fills up 21:08:23 `omni build_illumos` just builds illumos-omnios, so should take approximately as much resources as an illumos-gate build. nothing special there 21:09:10 even without compression that workspace with tonnes of crap in it is 18G 21:09:32 (sorry, I forgot about logicalreferenced) 21:10:01 sjorge: not sure how 50 wouldn't be enough 21:46:34 could have been some onu's around from before, i grabbed my old build vm 21:47:13 anyway, nee vm not on my laprop is doing build_illumos now, next ul is figuring out how to get the viona sruff in a pkg archive 21:59:41 15.1G ./build/illumos-gate 22:00:10 (^ with du -Ash. v with du -sh) 22:00:23 4.76G ./build/illumos-gate 22:00:38 Eeesh compression IS helpful. ;) 22:02:13 And sjorge if you're just changing viona you SHOULD be able to just replace the viona module as long as you've built in the same branch as whatever you're booting. 22:02:24 (No need to build the world to just alter one module's function.) 22:03:51 you want to make sure it _really_ matches your genunix, for CTF 22:04:04 adding mysterious lies to what mdb tells you won't help :) 22:04:16 or disable uniq when building the module, which I can't remember how to do 22:08:32 So create a be, replace just the module and boot to it woth -t incase things inevetably explode ... i'll try that tomorrow if the build succeeds 22:10:19 Do NOT forget to: 22:10:35 bootadm update-archive -R /path/to/mounted/new-be 22:11:08 In case you don't use `beadm activate` and instead pick it from loader (as I'm wont to do on experiments).. 22:53:29 [illumos-gate] 15198 libdladm: variable is used uninitialized -- Toomas Soome 23:02:07 danmcd I actually did spot it too, but forgot to file the issue for it... thanks!