Switch to DuckDuckGo Search
   May 29, 2020  
< | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | >


NOTICE: This channel is no longer actively logged.

Toggle Join/Part | bottom
[00:22:50] *** clapont <clapont!~clapont@unaffiliated/clapont> has quit IRC (Ping timeout: 246 seconds)
[00:23:24] *** roryrjb <roryrjb!rory@gateway/vpn/privateinternetaccess/roryrjb> has quit IRC (Ping timeout: 272 seconds)
[00:26:21] *** jamtorus <jamtorus!~quassel@s91904421.blix.com> has joined #illumos
[00:28:52] *** jellydonut <jellydonut!~quassel@s91904421.blix.com> has quit IRC (Read error: Connection reset by peer)
[00:34:27] *** clapont <clapont!~clapont@unaffiliated/clapont> has joined #illumos
[00:51:15] <LeftWing> am11: Out of interest, what did you need sdt.h for?
[00:58:34] *** ldepandis <ldepandis!~ldepandis@unaffiliated/ldepandis> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzz…)
[02:08:18] *** liv3010m <liv3010m!~liv3010m@77-72-245-190.fibertel.com.ar> has quit IRC (Ping timeout: 260 seconds)
[02:18:24] *** Kurlon_ <Kurlon_!~Kurlon@cpe-67-253-136-97.rochester.res.rr.com> has quit IRC (Remote host closed the connection)
[02:19:02] *** Kurlon <Kurlon!~Kurlon@167-48.gwi.net> has joined #illumos
[02:23:24] *** blackwood821 <blackwood821!~blackwood@c-174-49-16-176.hsd1.tn.comcast.net> has quit IRC (Remote host closed the connection)
[02:30:20] *** liv3010m <liv3010m!~liv3010m@77-72-245-190.fibertel.com.ar> has joined #illumos
[02:56:05] *** blackwood821 <blackwood821!~blackwood@c-174-49-16-176.hsd1.tn.comcast.net> has joined #illumos
[02:57:51] *** Kurlon <Kurlon!~Kurlon@167-48.gwi.net> has quit IRC (Read error: Connection reset by peer)
[02:57:56] *** Kurlon_ <Kurlon_!~Kurlon@167-48.gwi.net> has joined #illumos
[02:59:29] *** Kurlon_ <Kurlon_!~Kurlon@167-48.gwi.net> has quit IRC (Read error: Connection reset by peer)
[02:59:35] *** Kurlon <Kurlon!~Kurlon@167-48.gwi.net> has joined #illumos
[03:03:10] *** Kurlon_ <Kurlon_!~Kurlon@cpe-67-253-136-97.rochester.res.rr.com> has joined #illumos
[03:05:31] *** blackwood821 <blackwood821!~blackwood@c-174-49-16-176.hsd1.tn.comcast.net> has quit IRC (Ping timeout: 265 seconds)
[03:06:58] *** Kurlon <Kurlon!~Kurlon@167-48.gwi.net> has quit IRC (Ping timeout: 265 seconds)
[03:21:42] *** jcea <jcea!~Thunderbi@2001:bc8:2ecd:caed:7670:6e00:7670:6e00> has quit IRC (Quit: jcea)
[04:03:28] *** MillerBoss <MillerBoss!~shit@your.mom.loves.millerboss.com> has joined #illumos
[04:39:26] *** arnoldoree <arnoldoree!~arnoldore@113.210.191.186> has joined #illumos
[06:02:41] *** amrfrsh <amrfrsh!~Thunderbi@134.19.189.92> has quit IRC (Ping timeout: 246 seconds)
[07:02:25] *** roryrjb <roryrjb!rory@gateway/vpn/privateinternetaccess/roryrjb> has joined #illumos
[07:28:02] *** phyre <phyre!~phyre___@78.30.22.107> has joined #illumos
[07:56:28] *** clapont <clapont!~clapont@unaffiliated/clapont> has quit IRC (Ping timeout: 256 seconds)
[08:18:03] *** pwinder <pwinder!~pwinder@86.11.191.8> has joined #illumos
[08:29:42] *** wl_ <wl_!~wl_@2605:6000:1b0c:6025::87c> has quit IRC (Ping timeout: 260 seconds)
[08:30:59] *** BOKALDO <BOKALDO!~BOKALDO@91.105.119.143> has joined #illumos
[08:31:26] *** alanc <alanc!~alanc@inet-hqmc02-o.oracle.com> has quit IRC (Ping timeout: 260 seconds)
[08:33:35] *** wl_ <wl_!~wl_@cpe-108-167-3-102.neb.res.rr.com> has joined #illumos
[08:37:46] *** alanc <alanc!~alanc@inet-hqmc02-o.oracle.com> has joined #illumos
[08:52:23] *** KeiraT <KeiraT!~k4ra@gateway/tor-sasl/k4ra> has quit IRC (Ping timeout: 240 seconds)
[08:53:30] *** andy_js <andy_js!~andy@94.11.185.123> has joined #illumos
[08:59:37] *** KeiraT <KeiraT!~k4ra@gateway/tor-sasl/k4ra> has joined #illumos
[09:11:28] *** roryrjb <roryrjb!rory@gateway/vpn/privateinternetaccess/roryrjb> has quit IRC (Quit: leaving)
[09:29:08] *** jimklimov <jimklimov!~jimklimov@ip-86-49-254-26.net.upcbroadband.cz> has joined #illumos
[09:34:52] *** ptribble <ptribble!~ptribble@cpc92716-cmbg20-2-0-cust138.5-4.cable.virginm.net> has joined #illumos
[09:50:13] *** neuroserve <neuroserve!~toens@ip-94-114-237-8.unity-media.net> has quit IRC (Ping timeout: 258 seconds)
[09:51:20] *** jamtorus is now known as jellydonut
[09:54:53] *** neuroserve <neuroserve!~toens@ip-94-114-253-33.unity-media.net> has joined #illumos
[10:25:38] *** ldepandis <ldepandis!~ldepandis@unaffiliated/ldepandis> has joined #illumos
[10:29:21] *** wacki <wacki!~wacki@i577A5E34.versanet.de> has joined #illumos
[10:33:43] *** KeiraT <KeiraT!~k4ra@gateway/tor-sasl/k4ra> has quit IRC (Ping timeout: 240 seconds)
[10:39:43] *** KeiraT <KeiraT!~k4ra@gateway/tor-sasl/k4ra> has joined #illumos
[10:48:41] <sjorge> pmooney I'll do a new SmartOS PI build with the latest sync on top and see if things break... will give feedback on the CR tonight or tomorrow, more likely tomorrow
[11:06:05] <sjorge> QQ, did this pull in the bits skipped by papertigers in the last syncup?
[11:06:38] <sjorge> seeing changes to net_backend so I think so
[11:10:22] *** DocMnaugh <DocMnaugh!~mnrmnaugh@unaffiliated/mnrmnaugh> has quit IRC (Ping timeout: 260 seconds)
[11:29:38] <am11> LeftWing: one of the introspection case was failing without sdt.h: http://sprunge.us/WrBBT5.
[11:30:13] <sjorge> aah README.sync mentions net_backup stuff was indeed still skipepd as is save/restore
[11:30:24] <sjorge> eh not to bad
[11:30:37] <sjorge> PI is building so ETA is 4h for it to finish and I can reboot asfter work
[11:38:39] *** mnrmnaugh <mnrmnaugh!~mnrmnaugh@unaffiliated/mnrmnaugh> has joined #illumos
[12:00:55] *** pardis <pardis!~znc@quark.paardenvla.nl> has quit IRC (Quit: ZNC 1.7.4 - https://znc.in)
[12:03:34] *** pardis <pardis!~znc@quark.paardenvla.nl> has joined #illumos
[12:15:43] *** pardis <pardis!~znc@quark.paardenvla.nl> has quit IRC (Quit: ZNC 1.7.4 - https://znc.in)
[12:16:46] *** pardis <pardis!~znc@quark.paardenvla.nl> has joined #illumos
[12:33:26] *** BH23 <BH23!~BH23@santoroj.plus.com> has quit IRC (Ping timeout: 265 seconds)
[12:45:40] *** BH23 <BH23!~BH23@santoroj.plus.com> has joined #illumos
[12:46:37] *** clapont <clapont!~clapont@unaffiliated/clapont> has joined #illumos
[13:03:24] *** clapont <clapont!~clapont@unaffiliated/clapont> has quit IRC (Ping timeout: 265 seconds)
[13:05:16] *** clapont <clapont!~clapont@unaffiliated/clapont> has joined #illumos
[13:07:42] *** amrfrsh <amrfrsh!~Thunderbi@134.19.189.92> has joined #illumos
[13:25:41] *** mnrmnaugh <mnrmnaugh!~mnrmnaugh@unaffiliated/mnrmnaugh> has quit IRC (Remote host closed the connection)
[13:34:01] *** mnrmnaugh <mnrmnaugh!~mnrmnaugh@unaffiliated/mnrmnaugh> has joined #illumos
[13:42:58] <tsoome> wonderful statistics. zpool iostat 15; bandwidth is shown about 33M per line, but after 2 lines of output, I get pool size incremented by 1GB.
[13:43:37] *** sjorge <sjorge!~sjorge@unaffiliated/sjorge> has quit IRC (Remote host closed the connection)
[13:47:39] *** sjorge <sjorge!~sjorge@unaffiliated/sjorge> has joined #illumos
[14:01:27] *** andy_js <andy_js!~andy@94.11.185.123> has quit IRC (Read error: Connection reset by peer)
[14:01:45] *** andy_js <andy_js!~andy@94.11.185.123> has joined #illumos
[14:05:22] *** sjorge <sjorge!~sjorge@unaffiliated/sjorge> has quit IRC (Ping timeout: 256 seconds)
[14:11:46] *** sjorge <sjorge!~sjorge@unaffiliated/sjorge> has joined #illumos
[14:12:17] <sjorge> pmooney just booted on a PI with the bits, will test pcipassthru and such alter, but basic networking and stuff all seems fine :)
[14:12:34] <sjorge> also... why is the 'Version' capitalzied? `illumos Version joyent_20200529T085640Z 64-bit`
[14:12:55] <sjorge> wouldn't lower case V make more sense?
[14:13:04] <jlevon> annoys me too!
[14:14:53] <andyf> OmniOS r151035 Version omnios-master-a84f9c312d 64-bit
[14:15:15] <andyf> It was always capitalised when it said SunOS at the start - I assume that's why it's the default
[14:15:52] *** storkone2 <storkone2!~storkone@a80-101-69-245.adsl.xs4all.nl> has quit IRC (Read error: Connection reset by peer)
[14:18:30] *** storkone <storkone!~storkone@a80-101-69-245.adsl.xs4all.nl> has joined #illumos
[14:21:07] <am11> strange; i copied a tar.gz file using scp from ubuntu vm to macos host, it was successfully extracted it on mac. then i scp that tarball over to smartos vm, it failed to extract. if i upload the tarball to the server from mac then download it on smartos using curl, then it extracts successfully (it's the same .tar.gz file). looks like scp is corrupting some data during the (sparse?) trasfer.
[14:26:26] *** BOKALDO <BOKALDO!~BOKALDO@91.105.119.143> has quit IRC (Quit: Leaving)
[14:33:38] *** blackwood821 <blackwood821!~blackwood@c-174-49-16-176.hsd1.tn.comcast.net> has joined #illumos
[14:35:48] *** BOKALDO <BOKALDO!~BOKALDO@91.105.119.143> has joined #illumos
[14:43:25] <toastersonerson> am11 no probably our tar being nasty try gtar
[14:45:27] <sjorge> jlevon glad it's not just me
[14:52:30] <sjorge> pmooney: did the smbios version change? HWinfo now reports it as 0.0
[14:52:46] <sjorge> let me check some old screenshots if that is normal
[14:53:26] <sjorge> nvm, no change
[14:54:17] *** jcea <jcea!~Thunderbi@2001:bc8:2ecd:caed:7670:6e00:7670:6e00> has joined #illumos
[15:06:47] *** ldepandis <ldepandis!~ldepandis@unaffiliated/ldepandis> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzz…)
[15:10:31] <am11> toastersonerson: gtar also failed to extract this file when i scp'd from mac to smartos. it works if i upload to github release from macos, then download it on smartos.
[15:11:37] <toastersonerson> huh? ok intriguing. does the sha256sum change?
[15:20:08] <sjorge> Un8AY1be
[15:21:27] <toastersonerson> welp that looks like you burned a password
[15:21:41] <sjorge> Long live password managers :D
[15:44:00] *** tsoome_ <tsoome_!~tsoome@0133-2890-94a7-9997-2f80-4a40-07d0-2001.sta.estpak.ee> has joined #illumos
[15:46:27] *** tsoome <tsoome!~tsoome@148-52-235-80.sta.estpak.ee> has quit IRC (Quit: Leaving)
[15:54:26] *** tsoome_ <tsoome_!~tsoome@0133-2890-94a7-9997-2f80-4a40-07d0-2001.sta.estpak.ee> has quit IRC (Quit: Textual IRC Client: www.textualapp.com)
[15:56:01] *** tsoome <tsoome!~tsoome@0133-2890-94a7-9997-2f80-4a40-07d0-2001.sta.estpak.ee> has joined #illumos
[15:56:04] *** phyre <phyre!~phyre___@78.30.22.107> has quit IRC (Remote host closed the connection)
[15:56:11] *** tsoome <tsoome!~tsoome@0133-2890-94a7-9997-2f80-4a40-07d0-2001.sta.estpak.ee> has quit IRC (Client Quit)
[15:56:46] *** tsoome <tsoome!~tsoome@0133-2890-94a7-9997-2f80-4a40-07d0-2001.sta.estpak.ee> has joined #illumos
[15:58:27] *** KeiraT <KeiraT!~k4ra@gateway/tor-sasl/k4ra> has quit IRC (Remote host closed the connection)
[15:59:03] *** KeiraT <KeiraT!~k4ra@gateway/tor-sasl/k4ra> has joined #illumos
[16:31:52] <pmooney> sjorge: thanks for testing
[16:32:09] <pmooney> btw, if you're on older INTC hardware, the TPR shadowing stuff should work
[16:35:45] *** gh34 <gh34!~textual@cpe-184-58-181-106.wi.res.rr.com> has joined #illumos
[16:39:37] <sjorge> It's skylake EP
[16:39:54] <sjorge> I do have an Ivy Bridge EP but no windows VM on that
[16:40:17] <sjorge> I believe both APICv?
[16:40:58] <sjorge> Which If I got the FreeBSD phabricator correctly, is the key to not need the new TPR shadow stuff.
[16:41:03] <sjorge> I could be wrong though
[16:41:17] <pmooney> correct, APICv is superior to TPR shadowing
[16:55:45] <sjorge> Would also explain why win10 was never slow for me
[17:01:45] <pmooney> or illumos guests, for that matter
[17:13:32] *** ldepandis <ldepandis!~ldepandis@unaffiliated/ldepandis> has joined #illumos
[17:43:25] <am11> toastersonerson: it looked like some issue with .tar.gz, i transferred others successfully.
[17:44:07] <am11> speaking of which first Hello World from dotnet worked after trasferring the cross-compiled assets. so yay! :D
[17:44:23] <jlevon> am11: neat
[17:44:58] <am11> but it was followe by a coredump due to thread prio lowering assertion. jbk already explained what to do, so will fix it once other patches are merged. :)
[17:45:10] <sjorge> pmooney nahamu *squeeeeel* https://i.imgur.com/grQE2i0.png
[17:45:19] <sjorge> Will need to dig up a monitor!
[17:45:39] <sjorge> I was hoping the BAR high adress range would get us here
[17:45:49] <sjorge> This is using the bex firmware though
[17:45:58] <sjorge> actually.. andy's version of that
[17:46:16] <pmooney> yeah
[17:46:22] <andyf> It should be pretty much the same - the only difference (other than where it was built) is that mine has Woodstock's USDT patch
[17:46:54] <andyf> er, DSDT even
[17:47:31] <sjorge> I'll let you know later this weekend if there is output or not
[17:47:46] <sjorge> Last time I tried it didn't show up at all or would hang on boot
[17:51:51] <toastersonerson> Hmm looks like I need a new Workstation/gaming rig setup once this is on illumos
[17:53:38] <sjorge> toastersonerson CR is open
[17:53:48] <sjorge> but... maybe not windows has the ! icon next to the device
[17:53:48] <toastersonerson> neat !
[17:53:57] <sjorge> But before the CR hwinfo doesn't even see it
[17:54:13] <sjorge> Ah... ofcourse it is a none server card so the driver is refusing to attach -_-
[17:54:29] <sjorge> We probably need the same hacks as KVM in SMBIOS to hide we're bhyve/virtual
[17:54:51] <toastersonerson> does anybody know good motherboards which allow GPU passthrough. My current one does not have proper IOMMU
[17:55:08] <toastersonerson> and I probably will go with AMD because of that
[17:55:09] <sjorge> Looking for an old driver pre all the hacks and a win 7 iso :D
[17:55:31] <sjorge> papertigers and danmcd were looking at good workstation/server AMD boards recently
[17:55:58] <toastersonerson> Ryzen $NEWEST aswell?
[17:56:16] <rmustacc> I'd probably start with considering the CPU.
[17:56:19] *** nde <nde!uid414739@gateway/web/irccloud.com/x-rbkfesseiisozdkz> has joined #illumos
[17:56:28] <rmustacc> As the CPU is the first thing that determines whether or not you have VT-d and support for passthrough at all.
[17:56:35] <rmustacc> That will then dictate the motherboard solution space.'
[17:56:56] <rmustacc> If you get a CPU with no support, the motherboard doesn't matter at all.
[17:57:13] <toastersonerson> good to know. I'll have to look into Ryzen more in detail then
[18:00:20] <sjorge> hello new driver who this https://i.imgur.com/96kzykn.png
[18:01:37] <sjorge> OK reboot and now windows fails with VIDEO TDR FAIL
[18:01:46] <sjorge> which I beleive is the nvidia doesn't like VM error
[18:03:44] <sjorge> reboot after and it boots again, GPU at proper speed too now
[18:05:41] <sjorge> but still no driver attach, oh well :) it was not expecting to get this far
[18:05:50] <sjorge> Would be nice to see someone try with an AMD card
[18:09:53] <pmooney> toastersonerson: pci-passthru has not been wired up for illumos-bhyve on AMD yet
[18:11:53] *** pwinder <pwinder!~pwinder@86.11.191.8> has quit IRC (Quit: This computer has gone to sleep)
[18:16:01] <dsockwell> i thought about going for the server class of AMD hardware (is that always EPYC?) when i was considering upgrades. my concern was guaranteeing that I could use ECC RAM but i'd expect it to have the most PCI-passthrough support available.
[18:16:44] <dsockwell> not that i've done any research on that at all, don't take my word for it
[18:17:52] <pmooney> I imagine it would have the IOMMU resources needed for it.
[18:18:05] <pmooney> But our bhyve port does not have the ability to use them right now
[18:18:59] <toastersonerson> pmooney (IRC): sigh.... and the wait continues.
[18:19:02] <dsockwell> right, i was also living dangerously by assuming illumos would catch up before the hardware got replaced again
[18:19:28] <pmooney> it's less a matter of "catch up"
[18:19:33] <pmooney> and more a matter of "do the work"
[18:20:24] <dsockwell> yes, that
[18:21:01] * toastersonerson can't wait until I have a big enough company to justify hiring some people for illumos work
[18:21:18] <am11> when we cross-compile an executable and some shared libs (to be loaded by executable) using sysroot and gcc cross-toolchain for illumos, the /opt/local/lib directory is not searched by the compiled shared libs for dlopen calls during the runtime. `readelf -a *.so | grep RPATH` suggests that the libcoreclr.so is trying to open libicuuc.so but not searching /opt/local/lib. in fact, there is no RPATH in that
[18:21:20] <am11> libcoreclr.so. what is the best way to fix it? a) update gcc toolchain so it always burns that RPATH. b) extract icu package on (linux) build machine such that libicuuc.so lands in $SYSROOT/opt/local/lib. c) add RPATH in when CMAKE_CROSSCOMPILING is ON for illumos.
[18:22:19] <am11> my current workaround is to LD_LIBRARY_PATH=/opt/local/lib dotnet hewlloworld
[18:25:50] <dsockwell> is there a systemwide LD_LIBRARY_PATH analog you should configure? or perhaps move your shared libs to somewhere better?
[18:27:07] <am11> thing is, if i compile this binary (same code revision) on the target (smartos) machine, then i don't have to set LD_LIBRARY_PATH. it is just when i cross-compile it, it fails to load without setting this LD_LIBRARY_PATH=/opt/local/lib.
[18:28:04] <rmustacc> Well, the thing is that most illumos distributions don't use pkgsrc.
[18:28:08] <rmustacc> Some do and some don't.
[18:28:15] <rmustacc> So trying to add a run path to /opt/local/lib isn't really correct.
[18:28:41] <rmustacc> I would really encourage you to take the path that was done with the rust folks who statically build in necessary deps for the cross-compiler and allow the native compiler to get what's right for the environment.
[18:29:01] <rmustacc> In general I don't recommend static linking of deps, but in this environment, I think it probably makes more sense.
[18:33:43] <am11> rmustacc: would it be still bad if /opt/local/lib is added as an additional run path?
[18:36:04] *** Kurlon_ <Kurlon_!~Kurlon@cpe-67-253-136-97.rochester.res.rr.com> has quit IRC (Remote host closed the connection)
[18:36:40] *** Kurlon <Kurlon!~Kurlon@167-48.gwi.net> has joined #illumos
[18:36:56] <rmustacc> am11: If I'm running on omnios or somewhere else that doesn't use /opt/local/lib, yes.
[18:37:04] <rmustacc> You don't want to add every path for every illumos distro that may come.
[18:37:34] <rmustacc> For example, under OmniOS I may have a bunch of packages under /opt/ooce. I don't think you'd want that everywhere.
[18:37:50] <am11> there is an effort going on to statically link runtime and native libraries in host (https://github.com/dotnet/runtime/issues/37119), this can wait until that happens as it's not a blocker for our stage0 bootstrap build.
[18:38:25] <rmustacc> I mean, if it's a temporary thing, do what you need to make it work.
[18:38:34] <rmustacc> Longer term it's just not something you want.
[18:40:14] *** arnoldoree <arnoldoree!~arnoldore@113.210.191.186> has quit IRC (Quit: Leaving)
[18:41:23] <am11> rmustacc: sure, besides these bits will not be in the final package. this build is only to feed the package manager build. we would be using e.g. https://github.com/am11/runtime/releases/download/sunos-wip/dotnet-runtime-5.0.0-dev-illumos-x64.tar.gz on, for example, IPC's build machine to build the runtime from scratch. so these bootstrap/stage0 bits should be good enough to hold the candle for that (real)
[18:41:25] <am11> build. :)
[18:41:53] <rmustacc> OK.
[18:41:54] *** neuroserve <neuroserve!~toens@ip-94-114-253-33.unity-media.net> has quit IRC (Ping timeout: 240 seconds)
[18:42:53] <am11> (this tarball was genearted today using cross-compilation without any manual step)
[18:47:24] <rmustacc> Thanks for all your work on this!
[18:51:46] <sjorge> am11: not that I'd recommend it, but there is elfpatch to fix stuff like this
[18:51:57] <sjorge> It's still not a good idea though
[18:55:03] *** KeiraT <KeiraT!~k4ra@gateway/tor-sasl/k4ra> has quit IRC (Ping timeout: 240 seconds)
[18:56:05] *** KeiraT <KeiraT!~k4ra@gateway/tor-sasl/k4ra> has joined #illumos
[19:01:51] <sjorge> pmooney or any other bhyvey person... is there currently a way to tell bhyve to not anounce itself via cpuid?
[19:01:52] *** jellydonut <jellydonut!~quassel@s91904421.blix.com> has quit IRC (Quit: jellydonut)
[19:02:17] <pmooney> so that the nvidia driver can't tell it's being virtualized?
[19:03:05] <sjorge> yes
[19:03:23] *** jellydonut <jellydonut!~quassel@s91904421.blix.com> has joined #illumos
[19:04:43] <sjorge> The equalivantof vmwares 'hypervisor.cpuid.v0'
[19:04:49] <pmooney> AFAIK, it goes to pretty significant lengths to try to detect that
[19:04:55] <pmooney> beyond just the CPUID stuff
[19:05:23] <pmooney> there is not a configurable way to disable that, presently
[19:05:36] <sjorge> ack
[19:05:53] <pmooney> I'd like to make some of the paravirt stuff configurable
[19:06:05] <pmooney> so we could emulate KVM or hyper-v paravirt mechanisms (like clock)
[19:06:18] <pmooney> and if/when that's added, I could definitely see having a 'none' driver as well
[19:06:34] <sjorge> Oh right you had the KVM clock branch over at the joyent repo a while ago
[19:06:37] <pmooney> so nothing responds to those cpuid registers
[19:06:48] <sjorge> That did imply KVM KVM as string though
[19:07:55] <pmooney> yes, that's required for the capability to be detected by linux
[19:08:04] <pmooney> same reason to emulate the hyperv interfaces
[19:08:16] <pmooney> I don't think windows has a driver for the KVM paravirt clock
[19:08:28] <pmooney> it's certainly not going to grow support for a bhyve custom one
[19:08:44] <pmooney> so we might as well pretend to be hyperv so it doesn't need to hammer the hpet
[19:16:06] <sjorge> So you'd have 'standard' (bhybe), 'kvm', 'hypverv', 'none'
[19:16:07] <sjorge> type deal
[19:16:19] <pmooney> yeah, something like that
[19:17:05] <pmooney> I think in the long term, it will probably be most useful to default to KVM
[19:17:23] <pmooney> I don't think identifying as bhyve to the guest unlocks much for us today
[19:17:26] <toastersonerson> uh oh we seem to have another unknown key problem with some layouts that are too different than SUN.
[19:18:17] <toastersonerson> and it's blocking installation in some Asian language configurations
[19:25:13] <sjorge> I guess it doesn't yeah, I'd much rather see a bunch of this stuff end up under virtio though
[19:25:29] <sjorge> There is no reason the fancy KVM parav cluck stuff should only work when the hypervisor says I am KVM
[19:27:03] <danmcd> Pardon latency, sjorge.
[19:27:55] <danmcd> My frontrunner CPU for HDC3.0 is the Ryzen 7 3700x, and the frontrunner motherboard is the ASRock Rack X470D4U (2xGigE edition).
[19:28:31] <danmcd> I don't use bhyve or kvm on my HDC today, and it likely wouldn't need PCI passthru anyway, though, so I'm a simpler audience than most.
[19:31:25] <sjorge> toastersonerson ^
[19:32:19] <toastersonerson> :) that combo with PCI passthrough sounds interesting
[19:32:56] <pmooney> sjorge: it's not that it doesn't work, but just that Linux only bothers to check for it on KVM
[19:33:24] <am11> jlevon: a question about https://www.illumos.org/issues/4963, do you know which exact privilege the basic-set is missing which is required to change the thread priority (raise priority to the value where the same application lowered it from few cycles ago)? for example, rn `dotnet app.dll` triggers an assert "priority cannot be changed". but `sudo dotnet app.dll` exits gracefully.
[19:33:55] <am11> i was thinking to add that privilge to my user, and get by this issue for the time being.
[19:37:14] <dsockwell> sjorge: there used to be a patch for qemu-kvm that removed 'kvm' from somewhere. i recall that working with a windows VM and passthrough GPU for display a few years ago before i switched to AMD but i have no idea what nvidia is doing now
[19:37:35] *** amrfrsh <amrfrsh!~Thunderbi@134.19.189.92> has quit IRC (Ping timeout: 256 seconds)
[19:38:02] <dsockwell> would it make sense to try making Linux work with Nouveau before working on the Windows drivers?
[19:40:57] <sjorge> dsockwell yeah you need to hide your virtualized for nvidia
[19:41:02] <sjorge> and foce disable MSI
[19:41:17] <sjorge> I think we already have a flag for the later
[20:08:47] *** jamtorus <jamtorus!~quassel@s91904421.blix.com> has joined #illumos
[20:09:21] *** jellydonut <jellydonut!~quassel@s91904421.blix.com> has quit IRC (Read error: Connection reset by peer)
[20:16:56] *** jamtorus is now known as jellydonut
[20:17:26] *** amrfrsh <amrfrsh!~Thunderbi@134.19.189.92> has joined #illumos
[20:21:43] *** cantstanya <cantstanya!~chatting@gateway/tor-sasl/cantstanya> has quit IRC (Ping timeout: 240 seconds)
[20:22:46] <rmustacc> am11: If you look at the privileges manual page you probably want one of PRIV_PROC_PRIOUP or PRIV_PROC_PRIOCNTL.
[20:23:47] *** cantstanya <cantstanya!~chatting@gateway/tor-sasl/cantstanya> has joined #illumos
[20:29:41] <am11> rmustacc: thank you! i should have searched the manual. proc_prioup was the one required. for this i have a task in backlog to implement it using priocntl(2) directly (unless it gets addressed upstream first).
[20:35:54] <am11> so far, the other privilege we have set on top of basic set is proc_lock_memory, as coreclr on initialization requires either the platform to support membarrier_cmd_private_expedited, or its fallback mlock-based implementation. mantainers asked us if illumos supports another mechanism to lock memory (which doesn't require privileged user), we can implement it. so far, i haven't found any other way.
[20:38:17] <am11> s/mantainers/maintainers
[20:38:47] <rmustacc> What is the underlying thing it's trying to achieve? I ask as the first and second one seem different.
[20:39:02] <rmustacc> e.g. memory barriers and locking memory seem to solve different problems.
[20:55:26] <am11> > I am not sure I understand what you are asking for. If the membarrier syscall with MEMBARRIER_CMD_PRIVATE_EXPEDITED is not supported and the mlock fails, it is a dead end. We have no way to flush process write buffers in that case and runtime would crash intermittently during / after a GC.
[20:55:42] <am11> rmustacc: this was the exact comment. :)
[20:56:52] <am11> and the code that fails is in the flush process write buffers function: https://github.com/dotnet/runtime/blob/84ec25f80/src/coreclr/src/pal/src/thread/process.cpp#L3520
[20:57:54] <am11> (i asked for a way to elide this hard mlock requirement)
[20:59:28] <rmustacc> I see. So the real thing is that they need to coalesce all the threads.
[20:59:56] <rmustacc> And they're relying on a non-lazy mprotect to do so. I see.
[21:01:02] <rmustacc> I wonder what it is that Java and other multi-threaded runtimes do.
[21:07:32] <sjorge> pmooney: did anything change fbuf wise?
[21:07:57] <sjorge> realvnc is showing rainbow barf, then vmadmd drops the unix socket
[21:08:02] <sjorge> restart vmadmd and I can connect again
[21:08:06] <sjorge> before it worked OK
[21:08:25] <sjorge> I also tried with tigervnc, that one stil works fine
[21:10:12] <pmooney> not that I'm aware of
[21:10:42] <sjorge> update and refresh also seems slower, like really slow
[21:11:01] <sjorge> let me scan over the CR again
[21:11:44] <sjorge> nope, just the debug print change
[21:11:46] <sjorge> odd
[21:11:55] <pmooney> minor change to rfb.c
[21:11:58] <pmooney> lin 778
[21:12:00] <pmooney> *line
[21:13:27] <am11> rmustacc: coreclr's pal layer is basically a vm over windows apis used by the rest of the runtime. so this one is https://docs.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-flushprocesswritebuffers.
[21:13:58] <sjorge> pmooney connection ius good 1gbit to the CN
[21:14:11] <sjorge> It's pretty bad as I can see it refreshing hte blocks on tigervnc :O
[21:14:24] <sjorge> But seems odd form just that change
[21:14:35] <sjorge> I wonder if something else is up my end
[21:15:38] <pmooney> look at what seems to be running on the machine?
[21:15:42] <pmooney> is it loaded?
[21:16:42] <am11> maybe we can check how wine has it implemented, unless they too use mprotect there.
[21:17:06] <sjorge> pmooney no CN is not that busy, neither is the macbook
[21:17:15] <sjorge> network is 3% used
[21:17:21] <sjorge> Let me move the VM to the other CN
[21:19:03] <sjorge> Same result
[21:19:05] <am11> not yet implemented in wine: https://github.com/wine-mirror/wine/blob/279ac253/dlls/kernel32/process.c#L4120 -.-
[21:19:29] <sjorge> let me eleminate some variables as I am also unsing the update firmware binary
[21:19:32] <sjorge> give me asec to swap
[21:22:05] <sjorge> Hmmm it's the firmware
[21:22:27] <sjorge> I mean it's by no means fast on the old firmware... but it redraws the entire screen every second or so while before it took like 10
[21:22:34] <sjorge> probably closer to 5
[21:23:07] <sjorge> lets swap back to dot the I's
[21:23:53] <am11> similar story in qemu, no third option https://github.com/qemu/qemu/blob/595123df1/util/sys_membarrier.c#L24
[21:24:17] <sjorge> Yep it's the firmware!
[21:24:45] <sjorge> andyf have you use vnc/fbuf with the new firmware? it performs noticably worse on redraws than the old one
[21:25:02] <sjorge> pmooney not an issue with the change syncup, so still good for me
[21:27:19] <pmooney> ok, thanks
[21:35:14] <sjorge> more reason my GPU passtrhu although better than before is failing... the old card has no UEFI bios support
[21:35:30] <sjorge> I wonder if I can pick up a sub 80 EUR AMD card
[21:37:33] *** ypankov <ypankov!~ypankov@91.240.124.138> has joined #illumos
[21:53:33] *** blackwood821 <blackwood821!~blackwood@c-174-49-16-176.hsd1.tn.comcast.net> has quit IRC (Remote host closed the connection)
[21:53:51] *** blackwood821 <blackwood821!~blackwood@c-174-49-16-176.hsd1.tn.comcast.net> has joined #illumos
[21:58:29] <am11> sjorge: thanks for the elfpatch tip. and i will remember to avoid it. :)
[22:04:38] <am11> these stage0 binaries have short life in the process, so if LD_LIBRARY_PATH are intermittently used in a build bot (only), which produces the signed/trusted binaries to then again build the shippable product (the three-step model RedHat guys are using to get clean tarball out of dotnet/source-build), we won't need any hack like that on the user machine with final product.
[22:31:47] *** liv3010m <liv3010m!~liv3010m@77-72-245-190.fibertel.com.ar> has quit IRC (Ping timeout: 246 seconds)
[22:33:53] *** liv3010m <liv3010m!~liv3010m@77-72-245-190.fibertel.com.ar> has joined #illumos
[22:34:45] *** BOKALDO <BOKALDO!~BOKALDO@91.105.119.143> has quit IRC (Quit: Leaving)
[22:51:44] *** ngchk1 <ngchk1!~ngchk1@b2b-92-50-91-166.unitymedia.biz> has joined #illumos
[22:53:24] *** vgusev_ <vgusev_!~vgusev@188.187.60.230> has joined #illumos
[22:53:26] *** ngchk1_ <ngchk1_!~ngchk1@b2b-92-50-91-166.unitymedia.biz> has quit IRC (Ping timeout: 256 seconds)
[22:54:15] <jollyd> so... I just added coccinelle on OI : http://coccinelle.lip6.fr/ hopefully it can help the development on illumos... I'll look at fixing more test cases but the first results are promising.
[22:55:52] *** wacki <wacki!~wacki@i577A5E34.versanet.de> has left #illumos
[22:56:22] *** vgusev <vgusev!~vgusev@188.187.60.230> has quit IRC (Ping timeout: 246 seconds)
[22:57:40] <rmustacc> Neat.
[22:57:40] <jlevon> jollyd: neat
[23:11:19] *** neuroserve <neuroserve!~toens@ip-94-114-253-29.unity-media.net> has joined #illumos
[23:11:59] *** ptribble <ptribble!~ptribble@cpc92716-cmbg20-2-0-cust138.5-4.cable.virginm.net> has quit IRC (Remote host closed the connection)
[23:13:29] <LeftWing> jlevon, sjorge: I made it customisable, you can change to "version" in SmartOS if you want!
[23:19:06] *** blackwood821 <blackwood821!~blackwood@c-174-49-16-176.hsd1.tn.comcast.net> has quit IRC ()
[23:37:21] *** Kurlon_ <Kurlon_!~Kurlon@cpe-67-253-136-97.rochester.res.rr.com> has joined #illumos
[23:40:44] *** KeiraT <KeiraT!~k4ra@gateway/tor-sasl/k4ra> has quit IRC (Remote host closed the connection)
[23:41:15] *** Kurlon <Kurlon!~Kurlon@167-48.gwi.net> has quit IRC (Ping timeout: 256 seconds)
[23:41:55] *** KeiraT <KeiraT!~k4ra@gateway/tor-sasl/k4ra> has joined #illumos
top

   May 29, 2020  
< | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | >