Switch to DuckDuckGo Search
   April 14, 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 | >


NOTICE: This channel is no longer actively logged.

Toggle Join/Part | bottom
[00:01:50] <ypankov> that should actually be .B FX on its own line, even if we are talking about man(5) :)
[00:04:00] <ypankov> LeftWing: BTW, was the idea with moving man sections dropped?
[00:04:15] <LeftWing> Oh, no, sorry I've just been busy with other things
[00:04:27] <LeftWing> It's still a good idea and I don't think anybody really argued with it
[00:04:32] <LeftWing> Just a matter of getting the work done!
[00:04:56] <wilbury> ypankov: i only did it in line with current style.
[00:05:10] <rmustacc> I don't believe so.
[00:05:40] <LeftWing> ypankov: There was some feedback on my draft IPD that I should finalise
[00:10:19] *** andy_js <andy_js!~andy@90.218.209.121> has quit IRC (Quit: andy_js)
[00:16:31] *** Kruppt <Kruppt!~Kruppt@50-111-59-169.drhm.nc.frontiernet.net> has quit IRC (Quit: Leaving)
[00:19:23] <ypankov> wilbury: what you did is correct, yes, sorry for the noise
[00:22:00] <wilbury> when the general style cleanu will happen, then this can be changed, too.
[00:22:52] <wilbury> sleep mode, bbl &
[00:24:32] *** phyre__ <phyre__!~phyre___@78.30.20.36> has quit IRC (Remote host closed the connection)
[00:35:01] *** neirac <neirac!~cneira@pc-4-149-45-190.cm.vtr.net> has quit IRC (Ping timeout: 264 seconds)
[01:08:34] *** varna <varna!~varna@60.176.146.221> has quit IRC (Ping timeout: 240 seconds)
[01:08:51] *** varna <varna!~varna@60.176.146.221> has joined #illumos
[01:14:40] *** hww3 <hww3!~hww3@c-73-128-248-73.hsd1.md.comcast.net> has quit IRC (Ping timeout: 256 seconds)
[01:17:51] *** ldepandis <ldepandis!~ldepandis@unaffiliated/ldepandis> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzz…)
[01:21:00] *** hww3 <hww3!~hww3@c-73-128-248-73.hsd1.md.comcast.net> has joined #illumos
[01:21:06] *** neirac <neirac!~cneira@pc-4-149-45-190.cm.vtr.net> has joined #illumos
[01:28:30] <neirac> toastersonerson1 if you have time, could you take a look at these changes? https://github.com/cneira/nomad/commit/a18f4cf273333f7f40a9c0096bde9be87fb486e0 if they could be improved or any issues you see, these are for porting nomad to illumos
[01:40:16] <LeftWing> neirac: I suspect you want "ipadm show-prop -c -o property,current -p smallest_anon_port,largest_anon_port tcp"
[01:40:19] <LeftWing> Instead of ndd
[01:57:07] <neirac> LeftWing thanks a lot!
[01:58:58] *** ldepandis <ldepandis!~ldepandis@unaffiliated/ldepandis> has joined #illumos
[02:05:06] <neirac> toasterson1, LeftWing this one as well these are gopsutil changes that Smithx10 had and also some changes on ioctls https://github.com/cneira/nomad/commit/fa9d51c7ab84d44b456ef556fbfb9e92f7d23cf8
[02:06:46] <Smithx10> neirac: i got omnios running and tried your changes, i pm'd ya
[02:08:34] <ypankov> neirac: fwiw, illumos is spelled all lowercase
[02:08:48] <LeftWing> Indeed!
[02:10:49] <LeftWing> You have some "sunos_amd64" bits in that last patch -- should that just be "illumos_amd64" like the GOOS/GOARCH pair?
[02:15:35] *** hww3 <hww3!~hww3@c-73-128-248-73.hsd1.md.comcast.net> has quit IRC (Remote host closed the connection)
[02:16:01] *** hww3 <hww3!~hww3@c-73-128-248-73.hsd1.md.comcast.net> has joined #illumos
[02:25:25] <neirac> LeftWing I'll need to change that
[02:25:50] <neirac> ypankov thanks a lot I always used uppercase I, now I know
[02:26:09] *** gh34 <gh34!~textual@cpe-184-58-181-106.wi.res.rr.com> has quit IRC (Quit: Textual IRC Client: www.textualapp.com)
[02:34:12] *** nde <nde!uid414739@gateway/web/irccloud.com/x-jdbbekhgurvyxqmg> has quit IRC (Quit: Connection closed for inactivity)
[03:06:51] *** wacki <wacki!~wacki@i577B8C94.versanet.de> has quit IRC (Ping timeout: 260 seconds)
[03:26:44] *** ldepandis <ldepandis!~ldepandis@unaffiliated/ldepandis> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzz…)
[03:41:10] *** am11 <am11!54f985dd@dsl-hkibng22-54f985-221.dhcp.inet.fi> has joined #illumos
[03:41:34] *** nde <nde!uid414739@gateway/web/irccloud.com/x-bufkkuwxklyuuhzw> has joined #illumos
[03:43:37] *** jcea <jcea!~Thunderbi@2001:bc8:2ecd:caed:7670:6e00:7670:6e00> has quit IRC (Quit: jcea)
[04:25:10] <jbk> pmooney: i think your fix looks ok.. i do have a few small questions -- if you want to do a PR, I can put those in there, or do them here, whatever works
[04:25:40] <pmooney> depends on the nature of the question
[04:25:48] <pmooney> if they're nits, probably a PR
[04:25:55] <pmooney> anything bigger than that, and I can iterate first
[04:26:42] <jbk> just since c_fired is being set outside of a mutex, are there any consistency concerns there?
[04:27:17] <jbk> (in vmm_glue_callout_handler)
[04:27:38] <pmooney> no more concerns than manipulating c_flags outside of a mutex, haha
[04:27:59] <jbk> or might a barrier before invoking the callback be sufficient?
[04:28:00] <pmooney> but now c_fired is _only_ modified in that handler setup
[04:28:16] <jbk> well.. that's how we got here in the first place :)
[04:28:19] <pmooney> well, it's going to be in that same thread
[04:28:57] <pmooney> so I don't think a barrier is necessary
[04:29:22] <pmooney> if the thread happens to migrate between the c_fired assignment and where c_fired is checked, barriers will occur anyways
[04:31:18] *** idodeclare <idodeclare!~textual@cpe-76-185-177-63.satx.res.rr.com> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzz…)
[04:31:53] <pmooney> only the callout handler checks c_fired
[04:32:03] <pmooney> so all references to it will be in the context of the handler
[04:35:41] <Smithx10> Anyone know a good way to find the illumos of cpufreq/cpuinfo_max_freq
[04:35:59] <Smithx10> kstat has cpu_info clock, but i dont think it exposes max_freq
[04:36:21] *** arnoldoree <arnoldoree!~arnoldore@2001:d08:103e:81a8:6031:dc2e:a505:4e75> has joined #illumos
[04:39:40] <jbk> ok.. i _think_ I've convinced myself it should work :)
[04:54:37] <Smithx10> HmMM i can't find anything :(
[04:58:39] <jbk> cpuinfo_max_freq seems to only be for xen
[04:59:24] <jbk> i see a 'supported_frequencies_Hz' value in the cpu_info kstat
[04:59:37] <jbk> for my system, it's a colon separated list
[05:01:00] <Smithx10> hmm
[05:01:35] <Smithx10> I wonder if I dont see the other frequency because of VMware Workstations settings
[05:02:17] <Smithx10> I tried it on one of our nodes in the DC
[05:02:58] <Smithx10> https://gist.github.com/Smithx10/23992f15aa8b0f8310a0e8bb08cc3bfd
[05:02:59] <jbk> https://pastebin.com/WdfSfnDZ
[05:03:26] <Smithx10> Not sure if the Max turbo Freq is supposed to be listed there or not
[05:05:59] <Smithx10> I dont think that is used
[05:07:14] <LeftWing> turbo frequency sounds like something I'd expect rmustacc to know about!
[05:07:46] <Smithx10> I dont think that cpuinfo_max_freq actually reports the boost freq
[05:08:24] <Smithx10> think we are good with the kstat value. but It would be interesting to hear from rmustacc :P I always learn something
[05:37:14] *** neirac <neirac!~cneira@pc-4-149-45-190.cm.vtr.net> has quit IRC (Ping timeout: 240 seconds)
[05:37:44] *** neirac <neirac!~cneira@pc-4-149-45-190.cm.vtr.net> has joined #illumos
[06:06:21] *** idodeclare <idodeclare!~textual@cpe-76-185-177-63.satx.res.rr.com> has joined #illumos
[06:25:16] *** idodeclare <idodeclare!~textual@cpe-76-185-177-63.satx.res.rr.com> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzz…)
[06:32:57] *** lpsmith_ <lpsmith_!~lpsmith@unaffiliated/lpsmith> has joined #illumos
[06:33:02] *** jwit_ <jwit_!~jwit@gw.introvert.ca> has joined #illumos
[06:35:29] *** bdha1 <bdha1!~bdha@45.77.108.166> has joined #illumos
[06:35:50] *** ikonia_ <ikonia_!~irc@unaffiliated/ikonia> has joined #illumos
[06:35:59] *** jeffpc_ <jeffpc_!~jeffpc@josefsipek.net> has joined #illumos
[06:36:30] *** freezing_ <freezing_!~weechat@ec2-13-57-230-193.us-west-1.compute.amazonaws.com> has joined #illumos
[06:40:16] *** neirac <neirac!~cneira@pc-4-149-45-190.cm.vtr.net> has quit IRC (Ping timeout: 265 seconds)
[06:40:19] *** ikonia <ikonia!~irc@unaffiliated/ikonia> has quit IRC (*.net *.split)
[06:40:19] *** jeffpc <jeffpc!~jeffpc@josefsipek.net> has quit IRC (*.net *.split)
[06:40:19] *** jwit <jwit!~jwit@gw.introvert.ca> has quit IRC (*.net *.split)
[06:40:19] *** bdha <bdha!~bdha@45.77.108.166> has quit IRC (*.net *.split)
[06:40:19] *** freezing <freezing!~weechat@ec2-13-57-230-193.us-west-1.compute.amazonaws.com> has quit IRC (*.net *.split)
[06:40:19] *** lpsmith <lpsmith!~lpsmith@unaffiliated/lpsmith> has quit IRC (*.net *.split)
[06:55:52] <rmustacc> Smithx10, LeftWing: Generally speaking, no. Turbo boost frequencies do not show up and aren't enumerated by the processor.
[06:56:36] <rmustacc> Basically you'll see various P-states and other frequency options depending on ACPI configuration.
[06:57:48] <rmustacc> However, you can use MSRs to see this or I can observe it kicking in by just using the cpu perf counters with something that's in an infinite loop on cpu. However, one gotcha is that if deep C states are disabled in /etc/system, then you will not ender a deeper C state that allows other things to boost up. However you may still be able to get an all-cores turbo. But it's all a bit of a mess.
[06:59:27] <rmustacc> Smithx10: The maximum settable frequency that doesn't involve turbo boost is listed in the supported frequencies level.
[06:59:54] <rmustacc> In your example, you see the 2.5 GHz listed there.
[07:00:36] <rmustacc> Unfortunately, I don't think there is a programatic way to get the max turbo frequency or the all cores turbo.
[07:00:40] <rmustacc> But I'll poke around.
[07:04:22] *** Bdragon <Bdragon!~bdragon@drupal.org/user/53081/view> has quit IRC (Ping timeout: 260 seconds)
[07:06:03] *** Bdragon <Bdragon!~bdragon@drupal.org/user/53081/view> has joined #illumos
[07:09:31] *** wacki <wacki!~wacki@i577B8ED3.versanet.de> has joined #illumos
[07:10:04] <rmustacc> Hmm. Looks like there are. We could maybe add something like that to the kstat.
[07:35:41] *** neuroserve <neuroserve!~toens@ip-94-114-238-192.unity-media.net> has quit IRC (Ping timeout: 265 seconds)
[07:41:56] *** am11 <am11!54f985dd@dsl-hkibng22-54f985-221.dhcp.inet.fi> has quit IRC (Ping timeout: 240 seconds)
[07:44:12] *** nde <nde!uid414739@gateway/web/irccloud.com/x-bufkkuwxklyuuhzw> has quit IRC (Quit: Connection closed for inactivity)
[07:53:09] *** BOKALDO <BOKALDO!~BOKALDO@81.198.20.220> has joined #illumos
[07:59:39] *** idodeclare <idodeclare!~textual@cpe-76-185-177-63.satx.res.rr.com> has joined #illumos
[08:15:32] *** arnoldoree <arnoldoree!~arnoldore@2001:d08:103e:81a8:6031:dc2e:a505:4e75> has quit IRC (Ping timeout: 260 seconds)
[08:22:10] *** phyre__ <phyre__!~phyre___@78.30.20.36> has joined #illumos
[08:29:05] *** arnoldoree <arnoldoree!~arnoldore@2001:d08:1a80:d33d:a315:7930:58c3:4b76> has joined #illumos
[08:29:14] *** amrfrsh <amrfrsh!~Thunderbi@134.19.189.92> has quit IRC (Ping timeout: 240 seconds)
[08:49:50] *** alanc <alanc!~alanc@inet-hqmc01-o.oracle.com> has quit IRC (Remote host closed the connection)
[08:50:17] *** alanc <alanc!~alanc@inet-hqmc01-o.oracle.com> has joined #illumos
[08:57:50] *** tsoome <tsoome!~tsoome@91.209.240.229> has quit IRC (Read error: Connection reset by peer)
[08:58:58] *** tsoome <tsoome!~tsoome@91.209.240.229> has joined #illumos
[08:59:18] *** basvdlei <basvdlei!~basvdlei@lamuella.xs4all.nl> has quit IRC (Quit: basvdlei)
[09:10:46] *** basvdlei <basvdlei!~basvdlei@2001:980:a4c3:1:e6b9:7aff:fe9f:3993> has joined #illumos
[09:17:28] *** nbhauke <nbhauke!~hauke@55d45f36.access.ecotel.net> has joined #illumos
[09:20:17] *** arnoldoree <arnoldoree!~arnoldore@2001:d08:1a80:d33d:a315:7930:58c3:4b76> has quit IRC (Ping timeout: 260 seconds)
[09:23:03] *** nbhauke <nbhauke!~hauke@55d45f36.access.ecotel.net> has quit IRC (Quit: nbhauke)
[09:33:14] *** arnoldoree <arnoldoree!~arnoldore@2001:d08:1200:24ad:1552:d580:6351:79e4> has joined #illumos
[09:36:56] *** jimklimov1 <jimklimov1!~jimklimov@78.80.224.132> has joined #illumos
[09:41:17] *** arnoldoree <arnoldoree!~arnoldore@2001:d08:1200:24ad:1552:d580:6351:79e4> has quit IRC (Ping timeout: 260 seconds)
[09:48:44] *** trisk <trisk!~trisk@2601:196:4700:3a:8:20ff:fe3e:890e> has quit IRC (Quit: WeeChat 2.5)
[09:54:50] *** arnoldoree <arnoldoree!~arnoldore@2001:d08:1281:540b:5215:f467:9ceb:396b> has joined #illumos
[09:56:17] *** trisk <trisk!~trisk@2601:196:4700:3a:8:20ff:fe3e:890e> has joined #illumos
[09:59:22] *** arnoldoree <arnoldoree!~arnoldore@2001:d08:1281:540b:5215:f467:9ceb:396b> has quit IRC (Ping timeout: 260 seconds)
[10:00:29] *** trisk <trisk!~trisk@2601:196:4700:3a:8:20ff:fe3e:890e> has quit IRC (Client Quit)
[10:00:49] *** trisk <trisk!~trisk@2601:196:4700:3a:8:20ff:fe3e:890e> has joined #illumos
[10:11:46] *** arnoldoree <arnoldoree!~arnoldore@2001:d08:1a02:bb2e:d270:59e8:1bd7:ac87> has joined #illumos
[10:12:12] <toastersonerson1> @freenode_neirac:matrix.wegmueller.it: I've had a look. apart from the termios stuff which can be implemented without cgo it looks good.
[10:15:39] *** andy_js <andy_js!~andy@90.218.209.121> has joined #illumos
[10:18:02] *** arnoldoree <arnoldoree!~arnoldore@2001:d08:1a02:bb2e:d270:59e8:1bd7:ac87> has quit IRC (Ping timeout: 260 seconds)
[10:18:14] <kayront> question: is cached data read from an encrypted ZFS filesystem written cleartext to an L2ARC device?
[10:18:52] *** ptribble <ptribble!~ptribble@cpc92716-cmbg20-2-0-cust138.5-4.cable.virginm.net> has joined #illumos
[10:20:55] <tsoome_> kayront, that would defeat the purpose:)
[10:21:07] <kayront> i know, so just making 100% sure :D
[10:21:28] <Agnar> would be funny with the new persistent l2arc ;)
[10:21:40] <kayront> the persistent l2arc is a thing ?!
[10:21:49] <toastersonerson1> in zol yes
[10:21:50] <tsoome_> not yet on illumos.
[10:22:08] <kayront> are there plans to port it over?
[10:22:14] <kayront> that's a huge win!
[10:22:15] <toastersonerson1> 3525
[10:22:20] <kayront> huge I tell you
[10:22:20] <kayront> :p
[10:22:35] <toastersonerson1> thats the bugnumber not the year
[10:22:40] <kayront> lolol
[10:22:46] <Agnar> bwahahaha
[10:23:18] <kayront> by the way, i was trolling through manpages the other day, and some stuff to do with resource controls mentions a pooladm manpage, but at least in smartos there is no pooladm and no pooladm manpage
[10:23:31] <kayront> is it in illumos? if not, any idea why it was removed? it looks interesting (from oracle docs)
[10:23:54] <toastersonerson1> https://www.illumos.org/issues/3525
[10:24:09] <Agnar> kayront: it is in pkg:/service/resource-pools on oi
[10:25:16] <kayront> oh, so it was brutally eviscerated from smartos
[10:26:03] <kayront> Added by Sašo Kiselkov about 7 years ago.
[10:26:06] <kayront> you sure it's not the year?
[10:26:06] <kayront> :d
[10:27:01] <toastersonerson1> Well maybe bugnumbers are reverse indicative of the amount of years it takes to have a new feature.
[10:28:19] *** domag02 <domag02!b03fd4e2@catv-176-63-212-226.catv.broadband.hu> has joined #illumos
[10:28:32] <domag02> hi!
[10:29:42] <kayront> switching topic yet again (damn coffee), something I realized a couple of weeks back, been busy with other issues .. you know about the firewall framework described in svc.ipfd manpage? that seemed like a useful way to go about it, so i've built my automation on top of that in terms of firewalling.. until the time came to add ipv6 support, and that's when I discovered that said framework makes no provisions for ipv6: it is only possible to add
[10:29:42] <kayront> tcp and udp rules, and ipv6 needs icmp6 to work
[10:30:42] <kayront> bahamat suggested to add rules to the routing/ndp service (firewall framework svcprops), that seems like the cleanest idea, except the rules don't take icmp, only tcp/udp, but it is possible instead to specify a program that generates the rules for the service
[10:30:58] <kayront> i haven't come up with a cleaner way to do that. it seems like the way to go. opinions?
[10:31:02] *** arnoldoree <arnoldoree!~arnoldore@2001:d08:1201:2ece:185c:3e0b:deb:f797> has joined #illumos
[10:31:18] <Agnar> well, ipf does support ipv6...at least up to some point
[10:31:27] <Agnar> this ipf stuff is *old*
[10:31:39] <kayront> it does, although the manpage conveniently fails to mention that
[10:31:48] <kayront> and yes, coming from *bsd, believe me I miss pf
[10:32:08] <kayront> but unless I missed a major piece of knowledge, ipf is the choice for firewalling in illumos?
[10:33:50] <Agnar> it is the only choice at the moment
[10:34:12] <Agnar> and tbh: it does a very good job
[10:35:49] <kayront> well, if someone has more comments about that, i'd be happy to hear them. i'll have to fix that soon, for now i've reverted to using ipv4 because i really wanted some new services online
[10:36:26] <kayront> another thing that's been on my mind: i'm using zfs encryption in several of my smartos zones, after booting the zone it's necessary to zfs load-key manually, obviously
[10:36:44] <kayront> but services that use data from children of the encrypted dataset mostly happily start and don't notice that the data is missing
[10:37:41] <kayront> so i thought about adding a new dependency on a new service which when enabled load-key's and mounts the children, and when disabled umounts and unload-key's .. i haven't got to it yet, the question is, is it possible to make the service disabled on boot by default, and to prompt interactively (zfs load-key will do that) when running svcadm enable?
[10:38:00] <kayront> or any other ways of doing it that you suggest might be better
[10:39:04] <toastersonerson1> kayront (IRC): no services are enabled or disabled. other way would be to have a service that disables all encrypted services on shutdown and a cli which first calls zfs load-key and then enbles the services
[10:39:10] *** psydruid <psydruid!psydruidma@gateway/shell/matrix.org/x-krmkonqisxptbafb> has quit IRC (Quit: killed)
[10:39:10] *** Ericson2314 <Ericson2314!ericson231@gateway/shell/matrix.org/x-xtgiuxmselulpwyz> has quit IRC (Quit: killed)
[10:39:11] *** GrahamPerrin[m] <GrahamPerrin[m]!grahamperr@gateway/shell/matrix.org/x-zbkhlpmhihlxachz> has quit IRC (Quit: killed)
[10:39:33] *** TelegramBridge[m <TelegramBridge[m!telegramt2@gateway/shell/matrix.org/x-tktwezbkeegjmvxu> has quit IRC (Quit: killed)
[10:41:54] *** phyre__ <phyre__!~phyre___@78.30.20.36> has quit IRC (Ping timeout: 256 seconds)
[10:42:31] <domag02> kayront: a new milestone service?
[10:43:16] <kayront> interesting domag02; i haven't ever looked into milestone services, but i understand the concept
[10:44:03] <kayront> that could be it, and if i can't prompt for a password directly them maybe some small script that returns failure if keystatus=unavailable
[10:44:19] <kayront> then load-key manually, enable the service, and everything else should come back up
[10:50:49] *** TelegramBridge[m <TelegramBridge[m!telegramt2@gateway/shell/matrix.org/x-hnfysvjtgsczfzro> has joined #illumos
[10:54:53] *** arnoldoree <arnoldoree!~arnoldore@2001:d08:1201:2ece:185c:3e0b:deb:f797> has quit IRC (Ping timeout: 246 seconds)
[11:04:48] *** man_u <man_u!~manu@89-92-19-81.hfc.dyn.abo.bbox.fr> has joined #illumos
[11:08:41] *** arnoldoree <arnoldoree!~arnoldore@2001:d08:2070:d119:54da:c0f4:741f:c749> has joined #illumos
[11:16:57] *** arnoldoree <arnoldoree!~arnoldore@2001:d08:2070:d119:54da:c0f4:741f:c749> has quit IRC (Ping timeout: 252 seconds)
[11:19:40] *** GrahamPerrin[m] <GrahamPerrin[m]!grahamperr@gateway/shell/matrix.org/x-mvbdwuonpfpsuosf> has joined #illumos
[11:19:40] *** psydruid <psydruid!psydruidma@gateway/shell/matrix.org/x-ggblneeuxvtiswwx> has joined #illumos
[11:19:41] *** Ericson2314 <Ericson2314!ericson231@gateway/shell/matrix.org/x-iovepyokbwsdawiv> has joined #illumos
[11:20:56] *** neuroserve <neuroserve!~toens@ip-94-114-236-58.unity-media.net> has joined #illumos
[11:28:57] *** arnoldoree <arnoldoree!~arnoldore@2001:d08:1809:524f:b5b1:9595:659f:183e> has joined #illumos
[11:29:29] *** idodeclare <idodeclare!~textual@cpe-76-185-177-63.satx.res.rr.com> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzz…)
[11:34:52] *** arnoldoree <arnoldoree!~arnoldore@2001:d08:1809:524f:b5b1:9595:659f:183e> has quit IRC (Ping timeout: 256 seconds)
[11:36:31] *** am11 <am11!54f985dd@dsl-hkibng22-54f985-221.dhcp.inet.fi> has joined #illumos
[11:36:58] *** jimklimov1 <jimklimov1!~jimklimov@78.80.224.132> has quit IRC (Read error: Connection reset by peer)
[11:38:26] *** phyre__ <phyre__!~phyre___@37.29.208.213> has joined #illumos
[11:41:45] *** jimklimov1 <jimklimov1!~jimklimov@78.80.224.132> has joined #illumos
[11:42:43] *** KeiraT <KeiraT!~k4ra@gateway/tor-sasl/k4ra> has quit IRC (Ping timeout: 240 seconds)
[11:46:31] *** arnoldoree <arnoldoree!~arnoldore@2001:d08:1038:f5f1:d4bf:3980:518c:f598> has joined #illumos
[11:58:01] *** arnoldoree <arnoldoree!~arnoldore@2001:d08:1038:f5f1:d4bf:3980:518c:f598> has quit IRC (Ping timeout: 252 seconds)
[12:06:11] *** KeiraT <KeiraT!~k4ra@gateway/tor-sasl/k4ra> has joined #illumos
[12:12:03] *** arnoldoree <arnoldoree!~arnoldore@2001:d08:2181:ca32:95a:b5f1:226f:242f> has joined #illumos
[12:16:45] *** arnoldoree <arnoldoree!~arnoldore@2001:d08:2181:ca32:95a:b5f1:226f:242f> has quit IRC (Ping timeout: 240 seconds)
[12:17:14] *** amrfrsh <amrfrsh!~Thunderbi@134.19.189.92> has joined #illumos
[12:29:08] *** arnoldoree <arnoldoree!~arnoldore@2001:d08:1012:db15:e955:f2e1:ad85:be4e> has joined #illumos
[12:47:52] *** phyre__ <phyre__!~phyre___@37.29.208.213> has quit IRC (Remote host closed the connection)
[12:59:10] *** nde <nde!uid414739@gateway/web/irccloud.com/x-skjotqnhnygdrjrk> has joined #illumos
[13:13:33] *** catalinbostan <catalinbostan!~textual@95.77.171.190> has joined #illumos
[13:14:43] *** KeiraT <KeiraT!~k4ra@gateway/tor-sasl/k4ra> has quit IRC (Ping timeout: 240 seconds)
[13:17:32] *** KeiraT <KeiraT!~k4ra@gateway/tor-sasl/k4ra> has joined #illumos
[13:19:02] *** ypankov <ypankov!~ypankov@85.174.192.114> has quit IRC (Quit: leaving)
[13:25:58] *** ypankov <ypankov!~ypankov@85.174.192.114> has joined #illumos
[13:26:10] *** ypankov <ypankov!~ypankov@85.174.192.114> has quit IRC (Remote host closed the connection)
[13:26:22] *** wacki <wacki!~wacki@i577B8ED3.versanet.de> has quit IRC (Quit: Lingo: www.lingoirc.com)
[13:26:34] *** wacki <wacki!~wacki@i577B8ED3.versanet.de> has joined #illumos
[13:26:47] *** ypankov <ypankov!~ypankov@85.174.192.114> has joined #illumos
[13:28:35] *** arnoldoree <arnoldoree!~arnoldore@2001:d08:1012:db15:e955:f2e1:ad85:be4e> has quit IRC (Ping timeout: 252 seconds)
[13:30:33] *** idodeclare <idodeclare!~textual@cpe-76-185-177-63.satx.res.rr.com> has joined #illumos
[13:31:37] *** idodeclare <idodeclare!~textual@cpe-76-185-177-63.satx.res.rr.com> has quit IRC (Client Quit)
[13:33:17] *** KeiraT <KeiraT!~k4ra@gateway/tor-sasl/k4ra> has quit IRC (Quit: KeiraT)
[13:34:04] *** KeiraT <KeiraT!~k4ra@gateway/tor-sasl/k4ra> has joined #illumos
[13:42:41] *** arnoldoree <arnoldoree!~arnoldore@2001:d08:1a01:5ba:4802:109f:63d4:a8df> has joined #illumos
[13:43:45] *** phyre__ <phyre__!~phyre___@78.30.20.36> has joined #illumos
[13:45:01] *** amrfrsh <amrfrsh!~Thunderbi@134.19.189.92> has quit IRC (Quit: amrfrsh)
[13:50:48] *** ldepandis <ldepandis!~ldepandis@unaffiliated/ldepandis> has joined #illumos
[13:51:32] *** ypankov <ypankov!~ypankov@85.174.192.114> has quit IRC (Quit: Lost terminal)
[14:04:35] *** arnoldoree <arnoldoree!~arnoldore@2001:d08:1a01:5ba:4802:109f:63d4:a8df> has quit IRC (Read error: Connection reset by peer)
[14:06:54] *** amrfrsh <amrfrsh!~Thunderbi@134.19.189.92> has joined #illumos
[14:32:02] *** arnoldoree <arnoldoree!~arnoldore@2001:d08:2183:afdb:c1cd:b139:c4b1:918f> has joined #illumos
[14:33:49] *** phyre__ <phyre__!~phyre___@78.30.20.36> has quit IRC (Remote host closed the connection)
[14:36:05] *** gh34 <gh34!~textual@cpe-184-58-181-106.wi.res.rr.com> has joined #illumos
[15:06:32] *** phyre__ <phyre__!~phyre___@78.30.20.36> has joined #illumos
[15:13:08] *** neirac <neirac!~cneira@pc-4-149-45-190.cm.vtr.net> has joined #illumos
[15:14:54] *** neirac <neirac!~cneira@pc-4-149-45-190.cm.vtr.net> has quit IRC (Client Quit)
[15:15:25] *** phyre__ is now known as phyre
[15:16:48] *** neirac <neirac!~cneira@pc-4-149-45-190.cm.vtr.net> has joined #illumos
[15:17:04] *** phyre <phyre!~phyre___@78.30.20.36> has quit IRC (Quit: Saliendo)
[15:20:53] *** nbhauke <nbhauke!~hauke@55d45f36.access.ecotel.net> has joined #illumos
[15:24:23] *** phyre <phyre!~phyre___@78.30.20.36> has joined #illumos
[15:32:33] *** idodeclare <idodeclare!~textual@cpe-76-185-177-63.satx.res.rr.com> has joined #illumos
[15:33:37] *** idodeclare <idodeclare!~textual@cpe-76-185-177-63.satx.res.rr.com> has quit IRC (Client Quit)
[15:35:04] *** phyre <phyre!~phyre___@78.30.20.36> has left #illumos ("Saliendo")
[15:38:50] *** varna <varna!~varna@60.176.146.221> has quit IRC (Ping timeout: 256 seconds)
[15:46:07] *** nbhauke <nbhauke!~hauke@55d45f36.access.ecotel.net> has quit IRC (Quit: nbhauke)
[15:50:07] *** scoobybrrrrjesus <scoobybrrrrjesus!sid271506@gateway/web/irccloud.com/x-okfqkyxyskekyfnw> has quit IRC (Ping timeout: 240 seconds)
[15:51:45] *** scoobybrrrrjesus <scoobybrrrrjesus!sid271506@gateway/web/irccloud.com/x-wudkvqetebeykzjj> has joined #illumos
[15:57:51] *** scoobybrrrrjesus is now known as scoobybejesus
[16:07:38] *** Tempt_ <Tempt_!~avenger@mexico.purplecow.org> has joined #illumos
[16:07:51] *** Tempt_ <Tempt_!~avenger@mexico.purplecow.org> has quit IRC (Client Quit)
[16:07:51] *** Tempt <Tempt!~avenger@unaffiliated/tempt> has quit IRC (Read error: Connection reset by peer)
[16:08:00] *** Tempt <Tempt!~avenger@unaffiliated/tempt> has joined #illumos
[16:08:00] *** ChanServ sets mode: +o Tempt
[16:16:55] *** idodeclare <idodeclare!~textual@cpe-76-185-177-63.satx.res.rr.com> has joined #illumos
[16:38:47] *** idodeclare <idodeclare!~textual@cpe-76-185-177-63.satx.res.rr.com> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzz…)
[17:02:22] *** nbhauke <nbhauke!~hauke@55d45f36.access.ecotel.net> has joined #illumos
[17:07:19] *** nbhauke <nbhauke!~hauke@55d45f36.access.ecotel.net> has quit IRC (Quit: nbhauke)
[17:12:01] *** nbhauke <nbhauke!~hauke@55d45f36.access.ecotel.net> has joined #illumos
[17:14:21] *** man_u_ <man_u_!~manu@fob.gandi.net> has joined #illumos
[17:15:05] *** man_u <man_u!~manu@89-92-19-81.hfc.dyn.abo.bbox.fr> has quit IRC (Ping timeout: 240 seconds)
[17:15:06] *** man_u_ is now known as man_u
[17:24:52] <Smithx10> toastersonerson1: are you working any CNI / CSI stuff also?
[17:25:00] *** man_u_ <man_u_!~manu@89-92-19-81.hfc.dyn.abo.bbox.fr> has joined #illumos
[17:25:14] <toastersonerson1> yes eventually. I want a fully working kubelet
[17:27:47] *** man_u <man_u!~manu@fob.gandi.net> has quit IRC (Ping timeout: 256 seconds)
[17:27:48] *** man_u_ is now known as man_u
[17:34:28] *** catalinbostan <catalinbostan!~textual@95.77.171.190> has quit IRC (Quit: Textual IRC Client: www.textualapp.com)
[17:41:39] <gitomat> [illumos-gate] 12383 Slow down and lock up in mlxcx receive interrupt path -- Paul Winder <pwinder at racktopsystems dot com>
[18:01:20] *** neuroserve <neuroserve!~toens@ip-94-114-236-58.unity-media.net> has quit IRC (Ping timeout: 256 seconds)
[18:08:16] *** neuroserve <neuroserve!~toens@ip-84-118-128-205.unity-media.net> has joined #illumos
[18:12:55] *** KeiraT <KeiraT!~k4ra@gateway/tor-sasl/k4ra> has quit IRC (Remote host closed the connection)
[18:13:32] *** KeiraT <KeiraT!~k4ra@gateway/tor-sasl/k4ra> has joined #illumos
[18:20:45] <jbk> andyf: do you have a link to the JDK patch for using libdemangle-sys ?
[18:28:14] *** KeiraT <KeiraT!~k4ra@gateway/tor-sasl/k4ra> has quit IRC (Remote host closed the connection)
[18:28:45] *** KeiraT <KeiraT!~k4ra@gateway/tor-sasl/k4ra> has joined #illumos
[18:39:40] *** idodeclare <idodeclare!~textual@cpe-76-185-177-63.satx.res.rr.com> has joined #illumos
[18:41:13] *** idodeclare <idodeclare!~textual@cpe-76-185-177-63.satx.res.rr.com> has quit IRC (Client Quit)
[19:00:05] *** nbhauke <nbhauke!~hauke@55d45f36.access.ecotel.net> has quit IRC (Quit: nbhauke)
[19:09:21] *** am11 <am11!54f985dd@dsl-hkibng22-54f985-221.dhcp.inet.fi> has quit IRC (Remote host closed the connection)
[19:23:30] <Smithx10> toastersonerson1: neirac and I were also going down this path. Was curious where your abstraction is at for the CRI etc
[19:26:30] <andyf> jbk: looks like it’s here. https://github.com/omniosorg/omnios-build/commit/0441ce2bcbcf2bb99260f375059b4d1811d7217b#diff-36cbed4f6dc72f129552f528abe54289
[19:27:43] *** KeiraT <KeiraT!~k4ra@gateway/tor-sasl/k4ra> has quit IRC (Ping timeout: 240 seconds)
[19:28:12] <andyf> I’m not sure why it was done that was instead of a single patch
[19:28:22] *** KeiraT <KeiraT!~k4ra@gateway/tor-sasl/k4ra> has joined #illumos
[19:29:02] <andyf> with omnios having releases, we felt comfortable with doing this even with an unstable API
[19:29:28] <andyf> if it changes in gate, then that doesn’t affect the stable branches
[19:32:02] <jbk> one thing you could do, is use __cxa_demangle -- since you already have C++ code, you're already linking in libstdc++.. (clang also implements it)
[19:32:29] <jbk> and since you only care about C++ demangling, lack of other languages isn't an issue
[19:37:20] *** domag02 <domag02!b03fd4e2@catv-176-63-212-226.catv.broadband.hu> has quit IRC (Remote host closed the connection)
[19:39:43] <toastersonerson1> Smithx10 (IRC): My plan is: implement a dicker pendant that handles all functions that docker has plus some illumos specific stuffs. done 85% now and the add a kubelet on top so it can run inside a zone and provide clustering for that runtime. or probably multiple runtimes for each runtime interface as kubernetes defines them. My work is all located in this monorepo. https://git.wegmueller.it/OpenCloud/opencloud
[19:42:23] <toastersonerson1> the runtime will also include security and multi tenancy features. So that a kubelet for a tenant can run in a zone for that tenant and allocate only resources given to that tenant. The goal is to have no network conectivity for the runtime only inter zone data exchange. and handle the connections to cli that issues the commands be handled via the kubelet.
[19:46:25] <tsoome> help:) I have stack trace on sparc (kmdb), how can i get regs for specific point in stack? r specific register window?
[19:51:38] <jbk> i'm curious what other platforms do (if anything at all)
[19:56:21] *** nbhauke <nbhauke!~hauke@55d45f36.access.ecotel.net> has joined #illumos
[20:00:01] *** clapont <clapont!~clapont@unaffiliated/clapont> has quit IRC (Ping timeout: 265 seconds)
[20:01:24] *** clapont <clapont!~clapont@unaffiliated/clapont> has joined #illumos
[20:01:57] *** idodeclare <idodeclare!~textual@cpe-76-185-177-63.satx.res.rr.com> has joined #illumos
[20:05:27] *** man_u <man_u!~manu@89-92-19-81.hfc.dyn.abo.bbox.fr> has quit IRC (Quit: man_u)
[20:08:26] *** tsoome <tsoome!~tsoome@91.209.240.229> has quit IRC (Read error: Connection reset by peer)
[20:08:50] *** tsoome <tsoome!~tsoome@91.209.240.229> has joined #illumos
[20:10:30] <jbk> the other thing is if i ever do figure out a good way to do demanging output options, maybe it just does it through a separate function
[20:10:38] <jbk> leaving `sysdemangle` as-is
[20:11:24] *** jimklimov1 <jimklimov1!~jimklimov@78.80.224.132> has quit IRC (Quit: Leaving.)
[20:14:23] <ptribble> jbk: poking around the java source, it looks like linux (and bsd which I think means darwin here) use __cxa_demangle
[20:14:45] <jbk> we could do either then
[20:15:01] <jbk> both the gcc and clang runtimes provide that
[20:15:55] <jbk> (IIRC, it's actually requried as part of the IA64 C++ ABI, but both have more or less adopted most of the more platform-independent bits of it for their 64-bit C++ runtimes on most/all their supported platforms)
[20:16:09] <ptribble> __cxa_demangle would probably be cleaner as the code is then identical to other platforms
[20:16:39] <jbk> they == g++ and clang
[20:16:47] <jbk> i.e. it's probably pretty safe to use
[20:17:33] <jbk> it does mean you probably won't get demangling if symbols from other langs show up
[20:18:38] <jbk> so i suppose if someone was masochistic enough to write JNI code, and write JNI in something other than C or C++ (e.g. rust) and make it all work.. you might miss those
[20:18:56] <jbk> though AFAIK, no one's been so bold
[20:19:00] <jbk> (on any platform)
[20:19:25] <jbk> miss in might not get demangled
[20:35:23] <jbk> tsoome_: curious if this is still correct given the current zfs support in booter: https://grok.elemental.org/source/xref/illumos-joyent/usr/src/uts/common/fs/zfs/vdev.c?r=dd50e0cc#4420
[20:35:57] <jbk> (it's used to control when the 'bootfs' property can be set/changed)
[20:36:32] <jbk> oh.. it's the same in illumos-gate (can swap that out in the URL for that one)
[20:37:22] <tsoome> it is checking for case when you have multiple vdevs, we can not mount_rootfs() that
[20:37:51] <tsoome> that is, stripe of disks or mirrors or raidz*’s
[20:38:06] <tsoome> btw: https://paste.ec/paste/zB00SaHl#ArQuBWRuP9S+dProuIEAjRYW7OfpL1TDVcuCRRCHZWu
[20:38:45] <tsoome> a bit hacked (stmf_sbd is broken and used one from old be), but this was built with gcc 7.
[20:40:16] <igork> tsoome: congrats :)
[20:40:18] <jbk> tsoome_: at least part of that I think might be fixed by adding #include <sys/dmu.h> to sbd_zvol.c
[20:40:43] <jbk> or whatever the path in proto/ is
[20:41:19] <tsoome> jbk: hm. the crash was: https://paste.ec/paste/2ahQlHLw#6IvNz9ophEg4eUph621D2WEndfiHZrOAnAbb7jvsvwT
[20:41:50] <tsoome> but thanks for an idea.
[20:41:56] *** am11 <am11!54f985dd@dsl-hkibng22-54f985-221.dhcp.inet.fi> has joined #illumos
[20:42:09] <jbk> well to fix the missing symbols
[20:42:27] <tsoome> aa, nono, the missing symbols was deliberate:D
[20:42:38] <jbk> oh ok
[20:42:42] <tsoome> alternate option was to rm stmf_sbd :)
[20:43:26] <tsoome> because the one I did build from current gate is blowing up like above. happens with both gcc 4.4.4 and gcc 7
[20:43:31] <igork> tsoome: what is build time on your sparc ?
[20:43:45] <tsoome> for gate? ~2h
[20:43:55] <igork> for illumos build debug?
[20:44:02] <tsoome> gcc 7 is building ~48h
[20:44:11] <igork> huh
[20:44:33] <igork> i'm using ccache and have about 1.5h for illumos
[20:44:33] <tsoome> no, thats no-debug build.
[20:44:37] <igork> ok
[20:45:49] <tsoome> but, that does allow me to actually boot test the fixes:D
[20:46:54] *** Riastradh <Riastradh!~riastradh@netbsd/developer/riastradh> has quit IRC (Ping timeout: 265 seconds)
[20:46:54] <am11> hi, using `USRSTACK64_32` is giving me `error: 'USERLIMIT32' was not declared in this scope`, looks like `USERLIMIT32` is defined in `sys/param.h` under an ifndef _MACHDEP, but undef'ing it from user code has no effect.
[20:46:57] <am11> any suggestions on how to fix it?
[20:46:59] <jbk> i'd try to figure out what the corresponding line in _init is that's causing the unaligned access (i think that's the panic)
[20:48:03] <jbk> on a hunch, you might try printing out the definition of stmf_lu_provider_t
[20:49:30] <jbk> a uint8_t sandwiched between two pointer fields seems rife to maybe generate alignment issues (it should pad things out, but the ctf should say if that's happening or not)
[20:50:48] <jbk> am11: what are you trying to do?
[20:51:05] *** nbhauke <nbhauke!~hauke@55d45f36.access.ecotel.net> has quit IRC (Quit: nbhauke)
[20:51:35] <am11> jbk: working on https://github.com/dotnet/runtime/issues/34944 :)
[20:53:27] <am11> jbk: added an #elif defined(USRSTACK64_32) case before https://github.com/dotnet/runtime/blob/b3e791d/src/coreclr/src/pal/src/misc/sysinfo.cpp#L229
[20:53:43] <neirac> Smithx10 for issue 1, is it working on the Xeon output ?
[20:53:46] <am11> and got this error on smartos 2018 x86_64
[20:54:12] <Smithx10> neirac: yea, because of the regex
[20:54:17] <Smithx10> move that to kstat and we are good
[20:55:37] <jbk> i think you want to use either USERLIMIT or USRSTACK
[20:55:47] <jbk> and just build 64-bit only
[20:56:58] <jbk> tsoome: i thought we could read from raidz and striped pools
[20:59:03] <jbk> am11: which it should be seeing -- we have sys/vmparam.h and there's a test there
[20:59:16] <jbk> in the file you pasted
[21:02:58] *** tsoome <tsoome!~tsoome@91.209.240.229> has quit IRC (Read error: Connection reset by peer)
[21:03:17] *** tsoome <tsoome!~tsoome@91.209.240.229> has joined #illumos
[21:05:05] <am11> jbk: in `sys/vmparam.h`, i found `#define USRSTACK64_32 USERLIMIT32`, that `USERLIMIT32` comes from `sys/param.h`, where it is defined under `#if !defined(_MACHDEP)`. I tried to `#undef _MACHDEP` from user code (before `#include sys/param.h`), but still hitting the same error.
[21:06:07] <jbk> but why are you trying to use that define?
[21:06:16] <jbk> that's almost certainly not the thing you want
[21:07:10] <jbk> that is the stack limit for 32-bit processes running in a 64-bit kernel
[21:08:04] <am11> jbk, i could not find (just) `USRSTACK64`, as in `grep -R USRSTACK64 /usr/include` only yields `USRSTACK64_32` under an `#if defined(__amd64)`.
[21:08:31] <jbk> USRSTACK should be the correct value
[21:08:51] <jbk> if you're building a 32-bit object, it'll be the 32-bit limit, if you're building a 64-bit object, it'll be the 64-bit limit
[21:08:55] <danmcd> So tsoome: Do I understand correctly that *striping* is the issue, not raidz* or mirror?
[21:10:03] <jbk> you only need USRSTACK64_32 if you're one type (32/64 bit) and trying to mess with a process of a different type (32/64bit)
[21:10:19] <am11> jbk, oki, thanks. now it is giving me `error: 'USERLIMIT' was not declared in this scope` from `lpSystemInfo->lpMaximumApplicationAddress = (PVOID) USRSTACK;`
[21:11:14] <jbk> you might need to add -DMACHDEP when building that file
[21:11:20] <jbk> err
[21:13:56] <am11> tried adding `#define MACHDEP` on top of that file (before the first include), no effect (same error).
[21:13:57] <jbk> hrm
[21:14:14] <jbk> we don't ship the header file that defines that...
[21:16:45] <jbk> i'm not sure what the best way would be to get that then..
[21:18:13] <am11> yup, in sys/param.h, it is under `#if !defined(_MACHDEP)`, so `#undef _MACHDEP` had no effect either.
[21:18:40] <am11> will try to workaround it for now.
[21:18:45] <jbk> rmustacc: any thoughts on that ^^ (.net clr needs to know the value of USRSTACK, but to get the actual value requres machparam.h which isn't even installed into the proto area)
[21:20:35] <pmooney> jbk: https://github.com/rust-lang/rust/pull/71145
[21:21:39] *** Riastradh <Riastradh!~riastradh@netbsd/developer/riastradh> has joined #illumos
[21:21:40] <jbk> \o/
[21:24:08] <tsoome> danmcd yes
[21:24:46] <danmcd> Okay. Follow-up dumb question: if I create a pool that's a raidz with each vdev a mirror, is that bootable? Or does that violate "striping" too?
[21:25:21] <danmcd> (`zpool create vdev rpool raidz1 mirror disk0 disk1 mirror disk2 disk3 mirror disk4 disk5`)
[21:26:41] <toastersonerson1> am11 (IRC): in the PR https://github.com/dotnet/runtime/issues/34944 you are claiming, that mono is already available on solaris. Last I checked we needed some very hefty patrches and the solaris pthreads code was ripped out in 4.x has this changed? I don't see solaris listed as community supported platform.
[21:28:26] <tsoome> jbk danmcd : the problem s far was about fixed device paths in pool label, but thanks to LeftWing, we can scan for disks. However, to build up multi-vdev pool, we need the rootfs mount to build the pool config and that code is missing.
[21:29:06] <tsoome> danmcd: nested vdevs are not supported - you can not build raidz from mirrors
[21:29:25] <danmcd> Okay, so no raidz-of-mirrors or mirror-of-raidzs. Got it.
[21:31:23] <tsoome> what complicates the searc is the fact that vdev holds device list from the same vdev, if you have mirror, then both sides have both disks listed. if you have multiple mirrors, the whole pool config is in MOS.
[21:32:21] <am11> toastersonerson1, i was mainly reading the code in mono/mono repo, and seems like multiple patches were made for solaris in native and manged code, so I assumed some level of support is available. also on my smartos box `pkgin search mono | grep -i \\.net` returns `mono-4.0.4.1nb9`.
[21:33:19] <toastersonerson1> yes I tried to compile 5.x a while back but it required extensive source changes to the pthreads code and patches for that code too.
[21:33:21] <am11> toastersonerson1, some parts of mono are also added to dotnet/runtime repo, the issue is tracking coreclr && mono runtime + the bcl stuff.
[21:35:53] <LeftWing> tsoome: Right, the code is structured to open the pool in the full strength way if you have anything but a simple single vdev, as I recall
[21:36:11] <LeftWing> And that's all pretty dependent on the paths still working today
[21:36:33] <LeftWing> I tried restructuring some of it, but eventually backed that part of my change out before integration
[21:37:02] <LeftWing> I suspect it would be better to spend effort on a port of the common OpenZFS repo at this stage
[21:37:10] <LeftWing> (first)
[21:39:09] <tsoome> yep
[21:40:35] *** xzilla_ <xzilla_!~robert@pool-71-166-61-141.bltmmd.fios.verizon.net> has joined #illumos
[21:41:15] <ptribble> So __cxa_demangle does seem to work, java still works fine, but I can't find a way to test it properly.
[21:41:31] *** xzilla <xzilla!~robert@108.59.0.36> has quit IRC (Ping timeout: 250 seconds)
[21:41:57] <jbk> ptribble: any idea what java is even using that code for?
[21:42:14] <ptribble> Using standard g++ meakes it cleaner and more portable (to older branches, and to the original Solaris if someone wanted to use a gcc toolchain there)
[21:42:32] <ptribble> jbk: no idea, which is why I can't find a way to test it
[21:42:38] <jbk> heh
[21:43:02] <jbk> that's always fun..
[21:44:40] <ptribble> but simply copying a well used implementation stands a decent chance of doing the right thing
[21:45:45] <ptribble> There are new Java update releases just came out, but I don't see the corresponding tags in the openjdk repos yet
[21:46:05] <LeftWing> Are they still storing their stuff in Mercurial and just mirroring to GitHub?
[21:46:28] <ptribble> Yeah, the master is mercurial
[21:46:56] <ptribble> There was talk about moving,
[21:49:17] <ptribble> AdoptOpenJDK mirror the repos to github and then work off their mirrors
[21:52:13] <LeftWing> ptribble: What's the charter of AdoptOpenJDK? Are they a separate group of people with a more ... inclusive attitude/
[21:52:15] <LeftWing> *?
[21:53:38] <tsoome_> please review:) https://code.illumos.org/c/illumos-gate/+/502
[21:56:55] <jbk> heh.. stereo comments :P
[22:03:30] <tsoome_> :)
[22:03:33] <am11> jbk, to get by the error i used `#elif defined(USRSTACK) && defined(__sun) lpSystemInfo->lpMaximumApplicationAddress = (PVOID) 0xfffffd7fffe00000ul;`, will revisit it later once i get rest of the codebase to build. :)
[22:04:51] <ptribble> LeftWing: It's a community project to create redistributable openjdk builds
[22:05:12] <LeftWing> Ah, the official project doesn't create redistributable builds?!
[22:05:24] <ptribble> A lot of it came out of the user groups, it's quite independent
[22:05:24] <LeftWing> I clearly haven't been paying enough attention
[22:05:28] <LeftWing> Interesting
[22:05:30] *** BOKALDO <BOKALDO!~BOKALDO@81.198.20.220> has quit IRC (Quit: Leaving)
[22:05:48] <ptribble> The official openjdk builds are on a very limited set of platforms
[22:05:58] <LeftWing> Right, just the ones Oracle wants to support I guess?
[22:06:03] <ptribble> Right.
[22:06:19] <LeftWing> Well we're obviously never going to make that list haha
[22:06:25] <LeftWing> Even if we have a million users
[22:06:28] <ptribble> So there are people who want to see much wider adoption
[22:07:32] <ptribble> Adopt even produce some Solaris SPARC builds (Delphix sent them some hardware)
[22:09:50] <LeftWing> Wow
[22:11:26] <LeftWing> I mean, on some level, the more people who can and do use Java, the better it will be for Java in the long run
[22:11:53] <LeftWing> And, frankly, if it works on both Linux and FreeBSD there's really no reason it cannot work for us as well
[22:12:22] <ptribble> On cpu architectures supported by those other OSes, at least
[22:14:04] *** hww3 <hww3!~hww3@c-73-128-248-73.hsd1.md.comcast.net> has quit IRC (Ping timeout: 265 seconds)
[22:17:20] <LeftWing> Right
[22:17:37] <LeftWing> Code generation for more obscure CPUs is always going to be a challenge. It was for v8 in Node as well.
[22:19:21] *** hww3 <hww3!~hww3@c-73-128-248-73.hsd1.md.comcast.net> has joined #illumos
[22:19:22] <ptribble> Well, yes, I published Solaris 10 packages for Node
[22:19:40] <ptribble> Got quite a few people asking me for a SPARC port
[22:20:32] <LeftWing> As I recall, Aram had trouble trying to get SPARC support into Go as well, in part due to their Google-centric release engineering
[22:29:51] <toastersonerson1> gcc go has sparc support
[22:30:10] <toastersonerson1> Oracle Solaris seems to have switched to that.
[22:31:48] <ptribble> I noticed that; interesting choice, I tried that route and eventually gave up
[22:32:10] <toastersonerson1> to create sparc binaries?
[22:32:42] <ptribble> that was the thought, but you end up falling so far behind
[22:33:33] <LeftWing> Yeah I don't feel like gccgo is particularly sustainable
[22:33:50] <LeftWing> like GCJ
[22:34:20] <toastersonerson1> you mean gcc go ends up falling behind?
[22:34:25] *** hww3 <hww3!~hww3@c-73-128-248-73.hsd1.md.comcast.net> has quit IRC (Ping timeout: 264 seconds)
[22:34:26] <toastersonerson1> the compiler?
[22:34:50] <LeftWing> I think it's more that it almost certainly works quite differently to the primary Go toolchain, and that almost zero people test their software using it
[22:35:06] <LeftWing> So while it might plausibly work for some software, it's going to be a huge uphill battle
[22:35:09] <andyf> I've built a fair amount with gccgo, but just for testing
[22:35:27] <andyf> that's the whole point though, isn't it? go is a spec so it's really useful to have a second implementation
[22:35:45] <LeftWing> We used to use JRuby for bugs.illumos.org and it was a huge uphill battle, too, because it's not the toolchain that most people run their Ruby on and so it works a bit differently, and in ways that eventually become a problem.
[22:36:11] <LeftWing> It was good in that it was initially easy to scale up
[22:36:16] <toastersonerson1> it was my impression it should be astable spec so it should keep working. maybe not as optimized but for smaller stuff.
[22:36:22] <LeftWing> And bad in that it presented a whole additional class of bugs that nobody wanted to deal with
[22:37:44] <ptribble> A lot of projects, unfortunately, require the latest and greatest Go almost immediately, and gccgo is like 2 versions back even if you update gcc aggressively
[22:40:16] <LeftWing> They definitely encourage people to stay close on the release train
[22:40:41] <andyf> same with rust though.. so much stuff needs latest or even nightly features
[22:41:53] <wilbury> sorry for chiming in, but, is here someone involved in openindiana, specifically in oi-userland?
[22:42:08] <toastersonerson1> yes
[22:42:14] <toastersonerson1> mostly
[22:43:14] <gitomat> [illumos-gate] 12514 zfs: too few arguments to function 'spa_generate_rootconf' -- Toomas Soome <tsoome at me dot com>
[22:43:37] <toastersonerson1> what would you like to know?
[22:43:42] <wilbury> i try to build oi-userland when running from on-nightly BE with on-nightly publisher and desktop/gparted fails to install system/storage/parted
[22:44:10] <wilbury> as userland-incorporation is not on 9999.99.0.0
[22:44:42] <wilbury> and pkg://on-nightly/system/storage/parted at 1 dot 8.8-9999.99.0.0 is rejected by currently inastalled consolidation/userland/userland-incorporation at 0 dot 5.11-2020.0.1.12862
[22:45:11] <toastersonerson1> erm hmm that is a dependency problem.... whats the require dependencies of desktop/gparted?
[22:45:42] <toastersonerson1> you could nuke consolidation/userland/userland-incorporation it's a nitghtly anyway
[22:46:30] <toastersonerson1> alanc says they wanted a solid sparc backend. so yeah upstream go does not have that.
[22:46:44] <wilbury> ah ok
[22:47:43] <wilbury> thx
[22:49:16] <wilbury> i did not try to uninstall userland-incorporation but yes, it did not removed any other package
[22:49:20] <wilbury> s
[22:51:24] <toastersonerson1> you can uninstall it without a problem. It's there to keep the versions of packages to what is expected. on nightly you are running outside of that anyway so it becomes a hinderance. I though we added that to the userland build guides but we might not have.
[22:51:58] <wilbury> no mention of it on github page
[22:52:20] <toastersonerson1> ah which one specifically are you following?
[22:52:25] <wilbury> https://github.com/OpenIndiana/oi-userland
[22:52:34] <wilbury> wrong one?
[22:52:39] <toastersonerson1> yep
[22:52:45] <wilbury> yep wrong or yep right?
[22:53:16] <toastersonerson1> not extensive docs. just the readme :) http://docs.openindiana.org/dev/userland/
[22:53:32] <wilbury> toastersonerson1: gotcha! thanks
[22:53:35] *** jlevon <jlevon!jlevon@2a01:7e00::f03c:92ff:fefb:3ad2> has quit IRC (Quit: Coyote finally caught me)
[22:54:03] <toastersonerson1> although we do not have an illumos-gate build guide you will need to refer to illumos.org docs for that
[22:54:38] *** jlevon <jlevon!jlevon@2a01:7e00::f03c:92ff:fefb:3ad2> has joined #illumos
[22:54:40] <wilbury> env-prep to the rescue! so i don't have to hunt for missing BUILD_DEPENDS
[22:55:03] <wilbury> (i'm mostly with ports and pkgsrc last years)
[22:55:05] <alanc> We tried doing Google Go for SPARC for a couple years, but after the big budget/headcount cuts gave up on it, and went with the free solution
[22:55:30] <toastersonerson1> and I am pretty sure no on build instruction mentions specifics about the incorporations if you run into trouble with them.
[22:55:44] <alanc> Of course it helped that after the Docker port to Solaris died in those same cuts we didn't need bleeding edge Go as much anymore
[22:56:00] <wilbury> sigh, i gave up on SPARC back in 2016 when i left the job at sun partner
[22:57:31] <toastersonerson1> alanc I heard you are still producing OCI images though.
[22:59:44] <alanc> OCI as in Oracle Cloud Infrastructure, not Open Containers Intiative, as far as I know
[23:00:00] <toastersonerson1> not confusing at all....
[23:00:01] <wilbury> not Oracle Client Interface?
[23:00:14] <wilbury> (instantclient et al)
[23:00:22] <toastersonerson1> reverse acronym bingo yay
[23:02:24] <am11> are there any known plans for new SPARC chips in future, or has it been discontinued?
[23:03:32] *** tsoome_ <tsoome_!~tsoome@148-52-235-80.sta.estpak.ee> has quit IRC (Quit: This computer has gone to sleep)
[23:05:41] <alanc> Aram Hăvărneanu & Shawn Walker were the people trying to get SPARC backend upstream and failing to overcome Google's resistance - I just know we gave up, but not all the challenges they struggled with
[23:05:41] *** tsoome <tsoome!~tsoome@91.209.240.229> has quit IRC (Read error: Connection reset by peer)
[23:07:06] *** tsoome <tsoome!~tsoome@91.209.240.229> has joined #illumos
[23:07:37] <alanc> am11: SPARC is an open standard, so it's hard to say there's no company out there with plans or that it's been discontinued forever
[23:08:00] <alanc> but I wouldn't hold your breath for new chip designs
[23:08:00] <LeftWing> But perhaps not _that_ hard :P
[23:09:05] <alanc> I don't know what the people who had been making the SPARC cpus for the European Space probes are up to, but they also weren't making chips for systems you'd be buying
[23:10:56] *** tsoome_ <tsoome_!~tsoome@f046-b0d8-ca03-e9cd-2f80-4a40-07d0-2001.sta.estpak.ee> has joined #illumos
[23:11:31] <toastersonerson1> alanc (IRC): is there a known place where the stories got documented? We know from the FreeBSD guys, that there was apparently some problem with big endianness
[23:12:56] *** tsoome_ <tsoome_!~tsoome@f046-b0d8-ca03-e9cd-2f80-4a40-07d0-2001.sta.estpak.ee> has quit IRC (Client Quit)
[23:13:06] *** tsoome_ <tsoome_!~tsoome@f046-b0d8-ca03-e9cd-2f80-4a40-07d0-2001.sta.estpak.ee> has joined #illumos
[23:13:27] <alanc> I thought there was, but don't remember where
[23:15:36] <alanc> might have even been in this channel years ago, I thought Aram used to come here
[23:16:30] <rmustacc> am11, jbk: So can you all share a bit more information about what exactly the .net runtime is trying to achieve with that info? I ask because the positioning isn't guaranteed and in the face of aslr, it will probably change.
[23:16:58] <alanc> https://groups.google.com/d/msg/golang-dev/U6BeWzVzERQ/MVpmSIcMCwAJ
[23:18:16] *** wacki <wacki!~wacki@i577B8ED3.versanet.de> has quit IRC (Quit: Be back later ...)
[23:21:07] *** wacki <wacki!~wacki@i577B8ED3.versanet.de> has joined #illumos
[23:21:27] <toastersonerson1> ah thanks. yeah i only found that aswell... I'll have to send Aram a mail then to see if there is a repo with his work somewhere.
[23:22:15] *** hawk <hawk!~hawk@d.qw.se> has quit IRC (Quit: WeeChat 2.7.1)
[23:22:24] *** hawk <hawk!hawk@d.qw.se> has joined #illumos
[23:22:37] *** wacki_ <wacki_!~wacki@i577B8ED3.versanet.de> has joined #illumos
[23:22:42] *** wacki <wacki!~wacki@i577B8ED3.versanet.de> has quit IRC (Read error: Connection reset by peer)
[23:22:42] <am11> rmustacc, clr needs some system metric like information and limits in the PAL layer, which is platform abstraction for other parts such as VM (where codegen IL -> maccode transpires).
[23:23:25] <rmustacc> So is it looking for where the stack _actually_ is?
[23:24:01] <rmustacc> And what happens when this changes based on when hardware changes, e.g. when Intel has introduced 5-level paging.
[23:24:16] <rmustacc> Asking the system that the current value for all these things make sense.
[23:24:28] <rmustacc> I don't think trying to get an implementation constant from the current vm_param.h is the right way to do this.
[23:24:49] <am11> it is looking for userspace stack limit, internal variable calls it 'maximum application address'
[23:25:04] <rmustacc> Those are two different things though?
[23:25:12] <rmustacc> There's what's the largest address I can map and where the stack is.
[23:25:32] <alanc> toastersonerson1: https://github.com/4ad/go
[23:26:02] <toastersonerson1> thanks
[23:26:24] <am11> yes it is looking for largest address, the failure message was "The maximum application address is not known on this platform".
[23:26:35] <rmustacc> OK.
[23:26:49] *** wacki_ <wacki_!~wacki@i577B8ED3.versanet.de> has quit IRC (Ping timeout: 250 seconds)
[23:28:11] <rmustacc> Let me see if I can get a better means of that then.
[23:29:37] <am11> rmustacc, it is this control flow: https://github.com/dotnet/runtime/blob/b3e791d/src/coreclr/src/pal/src/misc/sysinfo.cpp#L220-L236
[23:29:56] <am11> I have just started to read `kstat_open(2)` to implement other parts of that sysinfo abstraction for Solaris (https://github.com/dotnet/runtime/blob/b3e791d/src/coreclr/src/pal/src/misc/sysinfo.cpp#L422), as the existing sysinfo and xsdew branches seems incompatible with Solaris. :)
[23:32:27] <danmcd> I'm seeing nightly fail on my illumos-gate build environment.
[23:32:29] <danmcd> mlxcx_ring.c: snprintf(tq_name, sizeof (tq_name), "%s_refill_%d_%ld",
[23:32:49] <danmcd> all of the other snprintf()s have (void) cast; this one doesn't. It makes my illumos-gate build barf.
[23:33:35] <danmcd> commit 22d052287ba7ed169757650e2eec25fedbae163a
[23:33:48] <danmcd> 12383 Slow down and lock up in mlxcx receive interrupt path (and friends)
[23:34:44] <LeftWing> danmcd: Did you take a look at the mail_msg from the build for that one?
[23:34:52] <LeftWing> (that is, the one the RTI)
[23:34:54] <andyf> no smatch showing in the mail_msg on the RTI
[23:35:00] <LeftWing> Yeeeeah
[23:35:10] <LeftWing> That'll do it
[23:35:16] <tsoome_> is gitomat slacking?
[23:35:16] <danmcd> I did not. I didn't even look at it - Garrett approved it before I had a chance.
[23:35:38] <danmcd> Luckily, I think it's just the one line. Once my build of -gate finishes, I'll propose a putback buddy (unless it's much much worse...).
[23:36:13] <LeftWing> mmm
[23:36:21] <LeftWing> It'd be good to make sure we explain that smatch is required
[23:36:31] <danmcd> Agreed.
[23:36:37] <LeftWing> To... everybody that needs to know that :P
[23:36:55] <danmcd> I caught it post-non-DEBUG, but pre-DEBUG, so I patched the only one that didn't get void-ed.
[23:37:00] <LeftWing> tsoome_: I will look!
[23:37:11] <danmcd> I think that's all it was (but yeah, no smatch is baaad, m'kay?).
[23:37:50] <danmcd> Ideally the DEBUG build will work. (And I was building to test a 12278 for RTI.)
[23:38:00] * LeftWing inches towards the machinery for project-provided nightly builds
[23:38:47] * danmcd needs to leave for dinner in 7mins, or would provide more immediate feedback
[23:39:11] <rmustacc> Will one of you reply to the RTI thread that this broke the build? Or should I?
[23:40:02] <danmcd> I will, once I see if my cure (the single line) will fix it. That'll take ~70mins, i.e. I'll be back after dinner to check in on it.
[23:40:11] <danmcd> Unless you wanna do it NOW, of course...
[23:40:28] <LeftWing> We should probably say something now
[23:40:37] <danmcd> Okay. I'll do that.
[23:40:54] <andyf> Probably best reply to /both/ threads...
[23:42:17] <LeftWing> tsoome_: I see gitomat messages from the most recent pushes?
[23:42:45] <tsoome_> but issue is not closed:)
[23:42:56] <LeftWing> oh, that's a separate body of software
[23:42:59] <LeftWing> I'll go look at that one
[23:43:04] <tsoome_> ou..
[23:44:50] <danmcd> Sent to advocates and Paul.
[23:44:59] <LeftWing> Thanks, Dan!
[23:45:16] <danmcd> I missed the DEBUG build window, but the nightly ground to a halt, so I kicked off a patched-build.
[23:45:45] <danmcd> It'll finish not long after dinner, and I'll be back here and on the advocates list to finish things. I suspect the one patch is all that was needed.
[23:46:12] <danmcd> (plus I get my 12278 build for free :) )
[23:46:21] <danmcd> Back in 60-80mins.
[23:47:27] <LeftWing> tsoome_: uncorked, I think
[23:47:38] <tsoome_> yes, thanks:)
[23:47:50] <tsoome_> so I can pour more in...
[23:48:07] <rmustacc> Well, not until the build's fixe.d
[23:48:09] <rmustacc> *fixed
[23:48:44] <rmustacc> If your nightly with your change can't come out clean on master (which it shouldn't right now), then we shouldn't be pushing.
[23:49:03] <danmcd> Oh not the push, just the "mail_msg" I'd need for RTI. :)
[23:51:17] <danmcd> Oh, damn, will need to do it again anyway.
[23:51:26] *** andy_js <andy_js!~andy@90.218.209.121> has quit IRC (Quit: andy_js)
[23:51:34] *** jeffpc_ is now known as jeffpc
[23:51:40] <rmustacc> Wasn't referring to your particular case Dan.
[23:56:38] *** ptribble <ptribble!~ptribble@cpc92716-cmbg20-2-0-cust138.5-4.cable.virginm.net> has quit IRC (Quit: Leaving)
top

   April 14, 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 | >