unfortunately, i don't think anyone's added support for mhd ioctls for nvme yet

i mean is there similar throw-away command in nvme that would do nothing, but would trigger reservation conflict still?

i think that would depend on the type of reservation

IIRC, it's modeled after scsi-3 PGRs, which can allow for different things from 'other' systems (e.g. can disallow most commands, just writes, etc...)

like if it's an exclusive reservation, it should be enough to attempt to read from a non-registrant

just looking at the command set spec (1.0c) -- sec 5.5 has a table that lists what are and aren't conflicts

so that might help pick something

[illumos-gate] 15225 Want bigger virtio 9P buffers -- Ryan Goodfellow <ryan.goodfellow⊙oc>

[illumos-gate] 15247 zfs_acl_chmod_aclmode_001_pos: tar extracts files in wrong directory -- Toomas Soome <tsoome⊙mc>

hi

Are there any x64 illumos based distributions with HDPI support? - Not sure if I need Wayland but am keen to port software to alt platforms

SamuelMarks: hdpi as in 200 dpi+?

It seems pretty unlikely

You'd probably need to update a bunch of github.com/illumos/gfx-drm to get support for newer graphics chips etc

SamuelMarks: Only if MATE can setup X.org up correctly

I have a AMD Radeon(TM) RX 6850M XT 12GB GDDR6 with a 4K monitor

you can normally set a env variable to enable system widget scaling of ui elements

it's somewhat of a mess really

MATE is not listed in the ArchWiki wiki.archlinux.org/title/HiDPI#:~:t…in%20high%2Dresolution%20mode%20yet.

And we don't have a driver for that Graphics card :)

aww

it's gtk

Yep but the utility is probably not there

Although the GNOME guide uses gsettings so that will work

Maybe

Maybe I'll use the Enlightenment manager distrowatch.com/search.php?desktop=Enlightenment

That brings the software side. But not the Graphics driver unfortunately

Hmm maybe I'll try a different kernel. Always keen for alt kernels and porting software to them

We would be happy if you port the driver :)

hmmm maybe

Send me a MemoServ message in a month and I'll give it a shot

MemoServ?

does anyone have an x86 crash dump I could have that crashed in some real fashion?

I'm just as puzzled as you as to how I've managed to not have a collection of them right now

or someone who has one and is willing to to mdb a little for me (andyf, do you still have the one you showed me before?)

thanks dan

Not ALL of them are real crashes (some are `reboot -d`) but enough are.

do you know which are which? :)

I think vmdump.0, e.g. is a real one.

pmooney: having the propolis standalone take the same args as the bhyve command would probably make it simpler to run in smartos. bahamat danmcd . I'm assuming the standalone is limited compared to server?

well, the core emulation bits are common across both

but the wiring for stuff like live-migration is targetted more for propolis-server

propolis-standalone is more of a developer playground, at least for now

And richlowe I'm serving those over "GigE" FiOS so it shouldn't take too long.

also, the bhyve command arguments aren't exactly great

fewer moving pieces, since it doesn't expect to be plugged into a control plane

(Quotes because really it's more like 900 +/- 50 Mbit.

)

richlowe: agreed. the alphabet soup is not wonderful

It is however very on brand BSD

well, there's been a general push to the key-value config stuff

I would expect propolis to work a bit like our zoneadmd eventually unless we do one process for both

jhb and co have been open-to and enthusiastic about moving to that model

toasterson: propolis is definitely designed for a single VM per process

single VM per process, and single process (propolis, bhyve, or KVM) per zone will give you better isolation properties

I meant one cli proces that quits and a long running "server"

that would be a rather worrying point of failure, I think?

not what I wanted to say. We have a cli "zoneadm" that start zoneadmd as the long running process that runs the zone

I imagine it could be similar like that.

where the cli start the server (or forks it)

mrrrow?

on brand BSD?

is there something I should snap

[illumos-gate] 15231 gcpu does not actually depend on acpica -- Dan Cross <cross⊙oc>