[illumos-gate] 15220 isatty should return reasonable errnos -- Robert Mustacchi <rm⊙fo>

has anyone tried to raise MAXPATHLEN?

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.

so I couldn't get a core dump.

I wonder what I should look for in logs, starting around 8am UTC or maybe a bit before

7am

three hours, gosh.

Interesting read rmustacc for IPD 38, although a lot of it goes way over my head.

So I've been looking around the viona doe a bit, woud a /etc/system tunable just need to force github.com/illumos/illumos-gate/blo…/uts/intel/io/viona/viona_tx.c#L100 to always return true to be effective?

s/doe/code/

I guess in theory this should do it right? github.com/omniosorg/illumos-omnios…os-omnios:viona_force_copy?expand=1

I'll try and figure out how to compile that when I am less sick.

sjorge: i think so (though testing is always better than guessing)...

the one thing that might be a concern from what I recall is it may prevent the VM front getting stuck

but it looked like we're somehow not triggering a notification on the read size (when the destination is a local non-VM zone)

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

if my recollection is correct, that may not address that aspect

(which might be fine for you uses, just pointing that bit out)

building omnios now, not sure how to get it on my actual hw though

and yeah it doesn't fix the issue of the local non-VM zone

but it should prevent the bhyve hangs

i think

build gonna take a while though

thats step 1 😅

Well failing on that, given kvm doesn't seem to compile :/

Not that I need kvm, but just following the omnios build instructions at this point

Oh I'm dumb, I think I know where I went wrong, off for another few hour wait

FWIW I hit this yesterday

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

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

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

If I made the vqsize vastly bigger I am sure it would happen less, or at least happen later, as sjorge has noted

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

from the dump at the time

I'm pretty sure in this case the rsync is waiting to write before it gets around to reading again

We're only going to send 256 * 1500 bytes in this configuration before we get corked

which is _tiny_

Yes, lowering vqsize from the default is a speedrun any% to get it for me

Glad someone was able to reproduce it reliably aside from me now

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

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 :/

build... all of omnios?

probably better for #omnios, but I'm also not sure why you'd do that.

Well i just ran omni build_illumos

so I would expect that to just be illumos-gate, well illumos-omnios I guess

yeah, definitely an answer I don't know, but for building illumos "Not that much"

rpool/builds/richlowe/illumos-git referenced 7.70G -

(that has a bunch of extra crap in it, so less than that much)

OK, gonna retry tomorrow and not run it in vmware fusion on my laptop

you might ask hadfl or andyf just to find out what it's going to do

maybe it'll build all the dependencies or something, but even that shouldn't be _that_ big

sjorge: Maybe make sure you have compression enabled on the pool

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.

Oh compression was probably not on

Gonna be smarter this time and set a quota on my build dataset so it doesn't cause havoc if it fills up

`omni build_illumos` just builds illumos-omnios, so should take approximately as much resources as an illumos-gate build. nothing special there

even without compression that workspace with tonnes of crap in it is 18G

(sorry, I forgot about logicalreferenced)

sjorge: not sure how 50 wouldn't be enough

could have been some onu's around from before, i grabbed my old build vm

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

15.1G ./build/illumos-gate

(^ with du -Ash. v with du -sh)

4.76G ./build/illumos-gate

Eeesh compression IS helpful. ;)

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.

(No need to build the world to just alter one module's function.)

you want to make sure it _really_ matches your genunix, for CTF

adding mysterious lies to what mdb tells you won't help :)

or disable uniq when building the module, which I can't remember how to do

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

Do NOT forget to:

bootadm update-archive -R /path/to/mounted/new-be

In case you don't use `beadm activate` and instead pick it from loader (as I'm wont to do on experiments)..

[illumos-gate] 15198 libdladm: variable is used uninitialized -- Toomas Soome <tsoome⊙mc>

danmcd I actually did spot it too, but forgot to file the issue for it... thanks!