00:31:20 <jbk> unfortunately, i don't think anyone's added support for mhd ioctls for nvme yet
00:32:41 <yuripv> i mean is there similar throw-away command in nvme that would do nothing, but would trigger reservation conflict still?
00:35:33 <jbk> i think that would depend on the type of reservation
00:36:47 <jbk> 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...)
00:38:00 <jbk> like if it's an exclusive reservation, it should be enough to attempt to read from a non-registrant
00:38:51 <jbk> just looking at the command set spec (1.0c) -- sec 5.5 has a table that lists what are and aren't conflicts
00:39:12 <jbk> so that might help pick something
10:55:43 <gitomat> [illumos-gate] 15225 Want bigger virtio 9P buffers -- Ryan Goodfellow <ryan.goodfellow⊙oc>
13:37:37 <gitomat> [illumos-gate] 15247 zfs_acl_chmod_aclmode_001_pos: tar extracts files in wrong directory -- Toomas Soome <tsoome⊙mc>
19:19:04 <SamuelMarks> hi
19:19:53 <SamuelMarks> 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
19:25:19 <nbjoerg> SamuelMarks: hdpi as in 200 dpi+?
19:34:22 <jclulow> It seems pretty unlikely
19:34:58 <jclulow> You'd probably need to update a bunch of https://github.com/illumos/gfx-drm to get support for newer graphics chips etc
19:35:39 <toasterson> SamuelMarks: Only if MATE can setup X.org up correctly
19:36:43 <SamuelMarks> I have a AMD Radeon(TM) RX 6850M XT 12GB GDDR6 with a 4K monitor
19:37:00 <nbjoerg> you can normally set a env variable to enable system widget scaling of ui elements
19:37:04 <nbjoerg> it's somewhat of a mess really
19:37:29 <toasterson> MATE is not listed in the ArchWiki https://wiki.archlinux.org/title/HiDPI#:~:text=HiDPI%20(High%20Dots%20Per%20Inch,in%20high%2Dresolution%20mode%20yet.
19:37:43 <toasterson> And we don't have a driver for that Graphics card :)
19:37:52 <SamuelMarks> aww
19:37:52 <nbjoerg> it's gtk
19:38:12 <toasterson> Yep but the utility is probably not there
19:38:39 <toasterson> Although the GNOME guide uses gsettings so that will work
19:38:41 <toasterson> Maybe
19:42:30 <SamuelMarks> Maybe I'll use the Enlightenment manager https://distrowatch.com/search.php?desktop=Enlightenment
19:43:04 <toasterson> That brings the software side. But not the Graphics driver unfortunately
19:48:57 <SamuelMarks> Hmm maybe I'll try a different kernel. Always keen for alt kernels and porting software to them
19:49:24 <toasterson> We would be happy if you port the driver :)
19:55:01 <SamuelMarks> hmmm maybe
19:55:16 <SamuelMarks> Send me a MemoServ message in a month and I'll give it a shot
20:07:23 <toasterson> MemoServ?
21:04:17 <richlowe> does anyone have an x86 crash dump I could have that crashed in some real fashion?
21:04:37 <richlowe> I'm just as puzzled as you as to how I've managed to not have a collection of them right now
21:05:00 <richlowe> 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?)
21:07:17 <danmcd> https://kebe.com/~danmcd/webrevs/fdinfo-dumps/
21:07:36 <richlowe> thanks dan
21:07:39 <danmcd> Not ALL of them are real crashes (some are `reboot -d`) but enough are.
21:07:45 <richlowe> do you know which are which? :)
21:07:46 <danmcd> I think vmdump.0, e.g. is a real one.
21:07:52 <Smithx10> 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?   
21:08:30 <pmooney> well, the core emulation bits are common across both
21:08:45 <pmooney> but the wiring for stuff like live-migration is targetted more for propolis-server
21:08:54 <pmooney> propolis-standalone is more of a developer playground, at least for now
21:09:03 <danmcd> And richlowe I'm serving those over "GigE" FiOS so it shouldn't take too long.
21:09:06 <richlowe> also, the bhyve command arguments aren't exactly great
21:09:10 <pmooney> fewer moving pieces, since it doesn't expect to be plugged into a control plane
21:09:18 <danmcd> (Quotes because really it's more like 900 +/- 50 Mbit.
21:09:25 <danmcd> )
21:09:26 <pmooney> richlowe: agreed. the alphabet soup is not wonderful
21:10:19 <jclulow> It is however very on brand BSD
21:10:37 <pmooney> well, there's been a general push to the key-value config stuff
21:10:55 <toasterson> I would expect propolis to work a bit like our zoneadmd eventually unless we do one process for both
21:10:57 <pmooney> jhb and co have been open-to and enthusiastic about moving to that model
21:11:13 <pmooney> toasterson: propolis is definitely designed for a single VM per process
21:11:55 <pmooney> single VM per process, and single process (propolis, bhyve, or KVM) per zone will give you better isolation properties
21:12:02 <toasterson> I meant one cli proces that quits and a long running "server"
21:12:48 <richlowe> that would be a rather worrying point of failure, I think?
21:13:19 <toasterson> not what I wanted to say. We have a cli "zoneadm" that start zoneadmd as the long running process that runs the zone
21:13:28 <toasterson> I imagine it could be similar like that.
21:13:42 <toasterson> where the cli start the server (or forks it)
21:19:52 <Reinhilde> mrrrow?
21:20:03 <Reinhilde> on brand BSD?
21:20:42 <Reinhilde> is there something I should snap
23:58:26 <gitomat> [illumos-gate] 15231 gcpu does not actually depend on acpica -- Dan Cross <cross⊙oc>