Switch to DuckDuckGo Search
   May 20, 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 | >

Toggle Join/Part | bottom
[00:15:11] *** phyre <phyre!~phyre___@78.30.22.107> has quit IRC (Remote host closed the connection)
[00:17:02] *** Riastradh <Riastradh!~riastradh@netbsd/developer/riastradh> has quit IRC (Remote host closed the connection)
[00:17:20] *** Riastradh <Riastradh!~riastradh@netbsd/developer/riastradh> has joined #illumos
[00:23:11] *** gh34 <gh34!~textual@cpe-184-58-181-106.wi.res.rr.com> has quit IRC (Quit: Textual IRC Client: www.textualapp.com)
[00:37:15] *** ngchk1_ <ngchk1_!~ngchk1@b2b-92-50-91-166.unitymedia.biz> has joined #illumos
[00:37:26] *** ngchk1 <ngchk1!~ngchk1@b2b-92-50-91-166.unitymedia.biz> has quit IRC (Remote host closed the connection)
[00:44:11] *** andy_js <andy_js!~andy@94.2.168.219> has quit IRC (Quit: andy_js)
[00:52:53] *** ldepandis <ldepandis!~ldepandis@unaffiliated/ldepandis> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzz…)
[01:13:46] *** liv3010m <liv3010m!~liv3010m@77-72-245-190.fibertel.com.ar> has quit IRC (Ping timeout: 265 seconds)
[01:14:28] *** liv3010m <liv3010m!~liv3010m@77-72-245-190.fibertel.com.ar> has joined #illumos
[01:56:43] *** ldepandis <ldepandis!~ldepandis@unaffiliated/ldepandis> has joined #illumos
[01:59:12] *** nbhauke <nbhauke!~hauke@55d45c4f.access.ecotel.net> has quit IRC (Ping timeout: 265 seconds)
[02:13:34] *** kayront <kayront!~kayront@unaffiliated/kayront> has quit IRC (Ping timeout: 240 seconds)
[02:14:08] *** kayront <kayront!~kayront@zbase.xen.prgmr.com> has joined #illumos
[02:14:31] *** kayront is now known as Guest12241
[02:14:52] *** nbhauke <nbhauke!~hauke@55d45c4f.access.ecotel.net> has joined #illumos
[02:16:59] *** ldepandis <ldepandis!~ldepandis@unaffiliated/ldepandis> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzz…)
[02:23:54] *** nbhauke <nbhauke!~hauke@55d45c4f.access.ecotel.net> has quit IRC (Ping timeout: 260 seconds)
[02:24:05] *** cantstanya <cantstanya!~chatting@gateway/tor-sasl/cantstanya> has joined #illumos
[02:31:51] *** nbhauke <nbhauke!~hauke@55d45c4f.access.ecotel.net> has joined #illumos
[03:34:22] *** Teknix <Teknix!~pds@69.41.134.110> has quit IRC (Read error: No route to host)
[03:35:18] *** Teknix <Teknix!~pds@69.41.134.110> has joined #illumos
[03:38:45] *** Teknix <Teknix!~pds@69.41.134.110> has quit IRC (Read error: Connection reset by peer)
[03:39:15] *** Teknix <Teknix!~pds@69.41.134.110> has joined #illumos
[03:48:06] <nahamu> I still can't pass in a GPU and have it work, not that I'm surprised.
[03:53:07] *** kovert <kovert!~kovert@204.141.173.249> has quit IRC (Ping timeout: 246 seconds)
[03:58:42] *** kovert <kovert!~kovert@204.141.173.249> has joined #illumos
[04:04:40] *** jcea <jcea!~Thunderbi@2001:bc8:2ecd:caed:7670:6e00:7670:6e00> has quit IRC (Quit: jcea)
[04:30:41] *** neirac <neirac!~cneira@pc-4-149-45-190.cm.vtr.net> has quit IRC (Ping timeout: 256 seconds)
[05:00:18] *** arnoldoree <arnoldoree!~arnoldore@2001:d08:1a00:eb45:9acb:d434:5802:3a63> has joined #illumos
[05:02:36] *** nde <nde!uid414739@gateway/web/irccloud.com/x-rgbcihtvtpdnxkys> has joined #illumos
[05:34:27] *** arnoldoree <arnoldoree!~arnoldore@2001:d08:1a00:eb45:9acb:d434:5802:3a63> has quit IRC (Ping timeout: 260 seconds)
[05:38:37] *** Teknix <Teknix!~pds@69.41.134.110> has quit IRC (Ping timeout: 264 seconds)
[05:40:16] *** Teknix <Teknix!~pds@69.41.134.110> has joined #illumos
[05:40:55] <LeftWing> One imagines patches both required and welcome!
[05:48:43] *** arnoldoree <arnoldoree!~arnoldore@113.210.177.165> has joined #illumos
[06:13:49] *** Teknix <Teknix!~pds@69.41.134.110> has quit IRC (Ping timeout: 246 seconds)
[06:14:24] *** Teknix <Teknix!~pds@69.41.134.110> has joined #illumos
[06:24:39] *** Teknix <Teknix!~pds@69.41.134.110> has quit IRC (Read error: Connection reset by peer)
[06:25:42] *** Teknix <Teknix!~pds@69.41.134.110> has joined #illumos
[06:27:56] *** Teknix <Teknix!~pds@69.41.134.110> has quit IRC (Read error: Connection reset by peer)
[06:28:16] *** Teknix <Teknix!~pds@69.41.134.110> has joined #illumos
[06:55:18] *** TelegramBridge[m <TelegramBridge[m!telegramt2@gateway/shell/matrix.org/x-qeiunvppzlevfxen> has quit IRC (Ping timeout: 260 seconds)
[06:56:55] *** TelegramBridge[m <TelegramBridge[m!telegramt2@gateway/shell/matrix.org/x-xvvelpjxaopmqzti> has joined #illumos
[07:22:02] *** BOKALDO <BOKALDO!~BOKALDO@46.109.201.132> has joined #illumos
[07:32:16] *** nde <nde!uid414739@gateway/web/irccloud.com/x-rgbcihtvtpdnxkys> has quit IRC (Quit: Connection closed for inactivity)
[07:39:31] *** jocthbr <jocthbr!~salci@138-122-44-143.host.cicloti.com.br> has quit IRC (Ping timeout: 260 seconds)
[07:44:48] *** jocthbr <jocthbr!~salci@138-122-44-143.host.cicloti.com.br> has joined #illumos
[07:45:28] *** vneurosere <vneurosere!~toens@212.100.42.172.fixip.bitel.net> has joined #illumos
[08:02:46] *** phyre <phyre!~phyre___@78.30.22.107> has joined #illumos
[08:11:28] *** jocthbr <jocthbr!~salci@138-122-44-143.host.cicloti.com.br> has quit IRC (Ping timeout: 256 seconds)
[08:13:08] *** jocthbr <jocthbr!~salci@138-122-44-143.host.cicloti.com.br> has joined #illumos
[08:20:59] *** pwinder <pwinder!~pwinder@86.11.191.8> has joined #illumos
[08:37:26] *** alanc <alanc!~alanc@inet-hqmc02-o.oracle.com> has quit IRC (Remote host closed the connection)
[08:37:54] *** alanc <alanc!~alanc@inet-hqmc02-o.oracle.com> has joined #illumos
[08:41:30] *** vneurosere <vneurosere!~toens@212.100.42.172.fixip.bitel.net> has quit IRC (Ping timeout: 256 seconds)
[09:00:10] *** ptribble <ptribble!~ptribble@cpc92716-cmbg20-2-0-cust138.5-4.cable.virginm.net> has joined #illumos
[09:11:18] *** ngchk1 <ngchk1!~ngchk1@b2b-92-50-91-166.unitymedia.biz> has joined #illumos
[09:13:14] *** ngchk1_ <ngchk1_!~ngchk1@b2b-92-50-91-166.unitymedia.biz> has quit IRC (Ping timeout: 256 seconds)
[09:37:29] *** jimklimov <jimklimov!~jimklimov@78.80.224.132> has joined #illumos
[09:52:33] *** andy_js <andy_js!~andy@94.11.185.123> has joined #illumos
[10:04:30] *** btibble <btibble!~brantibbl@c-69-94-200-89.hs.gigamonster.net> has quit IRC (Ping timeout: 260 seconds)
[10:04:32] *** btibble_ <btibble_!~brantibbl@c-69-94-200-89.hs.gigamonster.net> has quit IRC (Ping timeout: 260 seconds)
[10:27:18] *** natkin <natkin!~textual@cpe-76-185-177-63.satx.res.rr.com> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzz…)
[10:45:12] <sjorge> nahamu: I don’t think it works on upstream bhyve either too
[10:45:33] <sjorge> It think at the very least ed2k needs to be able to load the EFI firmware from the GPU
[10:45:46] <sjorge> Or the VGABIOS in case of CSM mode
[10:46:06] <sjorge> The VGABIOS changes that are on the bhyve call notes might get us closer though
[11:00:39] *** ldepandis <ldepandis!~ldepandis@unaffiliated/ldepandis> has joined #illumos
[11:18:53] *** fanta1 <fanta1!~fanta1@p200300f76bc408006c4dff792b220135.dip0.t-ipconnect.de> has joined #illumos
[12:05:36] *** jlevon <jlevon!jlevon@2a01:7e00::f03c:92ff:fefb:3ad2> has quit IRC (Quit: Coyote finally caught me)
[12:07:16] *** jlevon <jlevon!jlevon@2a01:7e00::f03c:92ff:fefb:3ad2> has joined #illumos
[12:34:39] *** kerberizer <kerberizer!~luchesar@wikipedia/Iliev> has joined #illumos
[13:37:48] *** ypankov <ypankov!~ypankov@188.162.166.52> has joined #illumos
[13:38:20] *** andy_js_ <andy_js_!~andy@94.11.185.123> has joined #illumos
[13:38:23] *** andy_js <andy_js!~andy@94.11.185.123> has quit IRC (Read error: Connection reset by peer)
[13:38:23] *** andy_js_ is now known as andy_js
[13:49:41] *** ypankov <ypankov!~ypankov@188.162.166.52> has quit IRC (Ping timeout: 258 seconds)
[14:12:18] *** gh34 <gh34!~textual@cpe-184-58-181-106.wi.res.rr.com> has joined #illumos
[14:25:21] *** ldepandis <ldepandis!~ldepandis@unaffiliated/ldepandis> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzz…)
[14:25:55] *** phyre <phyre!~phyre___@78.30.22.107> has quit IRC (Remote host closed the connection)
[14:47:01] *** neirac <neirac!~cneira@pc-4-149-45-190.cm.vtr.net> has joined #illumos
[14:59:18] *** ldepandis <ldepandis!~ldepandis@unaffiliated/ldepandis> has joined #illumos
[15:04:26] *** neirac <neirac!~cneira@pc-4-149-45-190.cm.vtr.net> has quit IRC (Quit: leaving)
[15:12:31] *** jcea <jcea!~Thunderbi@2001:bc8:2ecd:caed:7670:6e00:7670:6e00> has joined #illumos
[15:15:43] *** Kruppt <Kruppt!~Kruppt@50.111.31.166> has joined #illumos
[15:17:21] *** sjorge <sjorge!~sjorge@unaffiliated/sjorge> has quit IRC (Quit: 410 Gone)
[15:24:46] *** sjorge <sjorge!~sjorge@unaffiliated/sjorge> has joined #illumos
[15:28:33] <sjorge> jbk first PI updated, doing the other one now. Most traffic aside from admin runs over ixgbe... so it should tickle your changed code for taht
[15:33:34] *** btibble <btibble!~brantibbl@c-69-94-200-89.hs.gigamonster.net> has joined #illumos
[15:35:34] *** btibble_ <btibble_!~brantibbl@c-69-94-200-89.hs.gigamonster.net> has joined #illumos
[15:41:01] *** sjorge <sjorge!~sjorge@unaffiliated/sjorge> has quit IRC (Ping timeout: 264 seconds)
[15:44:02] *** sjorge <sjorge!~sjorge@unaffiliated/sjorge> has joined #illumos
[16:07:35] *** Kurlon_ <Kurlon_!~Kurlon@cpe-67-253-136-97.rochester.res.rr.com> has quit IRC (Remote host closed the connection)
[16:08:13] *** Kurlon <Kurlon!~Kurlon@167-48.gwi.net> has joined #illumos
[16:38:37] <jbk> i should get with andyf and see if I can get an omnioce pkg for it as well and post to illumos-discuss since ultimately I'd like to get the work upstreamed
[16:39:02] <jbk> just given the history of intel nics and intel drivers, want to be _really_ sure about things first :)
[16:40:22] *** hawk <hawk!hawk@d.qw.se> has quit IRC (Quit: WeeChat 2.8)
[16:41:34] <rmustacc> I'd recommend the distro lists rather than discuss if you're trying to reach a wider net.
[16:42:03] <rmustacc> But I'd also suggest how you want to intersect that with review, since things may or may not change that cause impact on the testing effort.
[16:42:05] *** hawk <hawk!hawk@d.qw.se> has joined #illumos
[16:50:36] *** jimklimov <jimklimov!~jimklimov@78.80.224.132> has quit IRC (Ping timeout: 256 seconds)
[16:53:08] *** blackwood821 <blackwood821!~blackwood@c-174-49-16-176.hsd1.tn.comcast.net> has joined #illumos
[17:02:06] *** ptribble <ptribble!~ptribble@cpc92716-cmbg20-2-0-cust138.5-4.cable.virginm.net> has quit IRC (Quit: Leaving)
[17:06:21] *** jollyd <jollyd!~alarcher@2a01:cb1d:611:bb00:8820:7cbd:8965:af56> has quit IRC (Ping timeout: 272 seconds)
[17:06:25] *** jollyd1 <jollyd1!~alarcher@lfbn-nic-1-142-60.w2-15.abo.wanadoo.fr> has joined #illumos
[17:06:58] *** nde <nde!uid414739@gateway/web/irccloud.com/x-gkkfphrzqgljmord> has joined #illumos
[17:12:35] <tsoome> those bugs. they multiply. at exponential rate, I say.
[17:15:08] <jollyd1> tsoome: :(
[17:17:02] *** jimklimov <jimklimov!~jimklimov@ip-86-49-254-26.net.upcbroadband.cz> has joined #illumos
[17:19:29] <rmustacc> tsoome: Sometimes it does feel that way. Often times you turn over a rock and find more.
[17:19:39] <rmustacc> As someone used to enjoy saying 'It's a target rich environment'
[17:20:39] <jollyd1> tsoome: any possibility to fix some of the issues using semantic patches with coccinelle?
[17:35:35] <nahamu> sjorge: and unlike qemu, it looks like bhyve doesn't currently support being passed a rom file on the command line, huh?
[17:36:57] <tsoome> jollyd1, maybe.
[17:37:53] <andy_js> Has anyone else noticed ftello returning bogus values recently?
[17:38:26] <andy_js> I’ve seen it return 0 when it should return something else, and in some cases, returning very large negative numbers.
[17:38:58] <andy_js> While I’ve not verified it yet, I suspect this change might have something to do with it: https://github.com/illumos/illumos-gate/commit/cd62a92d4a964bfe61d35ba2301b69e65e22a509
[17:39:36] <andy_js> So far this has caused issues with python which uses it in a number of places.
[17:41:19] <rmustacc> andy_js: I haven't seen it, but as likely the responsible person, happy to help dig if you can have some additional data.
[17:42:38] <andy_js> I have a test case which might be completely bogus but I don’t know. I’ll create a ticket once I’ve done more testing.
[17:42:55] <rmustacc> There were a bunch of issues with the different fell* bits being different. I tried to commonize them, but it could be that in the process I introduced a regression while trying to deal with the multiple, different broken onews.
[17:42:59] <rmustacc> *ones
[17:43:02] <rmustacc> OK, any additional details you have would be appreciated.
[17:43:12] <rmustacc> Apologies for the breakage..
[17:44:00] <rmustacc> andy_js: Also, if you have more details around why the on_fault/no_fault logic isn't working as expected in AWS, that'd be useful.
[17:45:21] <rmustacc> tsoome: It could be worse. You could be introducing all the bugs people hit like I am.
[17:45:25] <andy_js> I was not able to figure out why. AWS doesn’t make it particularly easy to debug stuff like that.
[17:45:55] <tsoome> rmustacc, been there, done that:D
[17:46:04] <rmustacc> My concern there is that this means you're going to hit similar problems elsewhere.
[17:46:10] <andy_js> I was wondering if it might actually be a bug in HVM though.
[17:46:10] <rmustacc> If that mechanism isn't working.
[17:46:33] <rmustacc> Well, you're getting a #GP injected right?
[17:48:17] *** jollyd1 <jollyd1!~alarcher@lfbn-nic-1-142-60.w2-15.abo.wanadoo.fr> has quit IRC (Quit: Leaving.)
[17:48:36] *** jollyd <jollyd!~alarcher@2a01:cb1d:611:bb00:8820:7cbd:8965:af56> has joined #illumos
[17:51:38] <jlevon> rmustacc: my idle concern was that it was injecting something other than the expected #gp
[17:51:49] <jlevon> rmustacc: so I'd be intrguied to confirm the trapno
[17:52:40] <rmustacc> Interesting. Yeah. Could be.
[17:53:01] <rmustacc> andy_js: What's the shape of your potentially bogus test case?
[17:53:25] <andy_js> I just open a file and seek to the end and then check what ftello returns.
[17:53:42] <rmustacc> 32-bit, lp64, or 64-bit program?
[17:53:51] <rmustacc> Erm, I meant file offset bits for 64-bit.
[17:53:54] <andy_js> But I’m building as 32-bit with LFS enabled to match python.
[17:54:07] <andy_js> I don’t yet know if it’s specific to 32-bit with LFS or not.
[17:54:12] <rmustacc> OK. That's fine.
[17:54:16] <rmustacc> I'll poke at this a bit as well.
[17:55:06] <rmustacc> There had been suspiciously few bugs noted after touching so much of stdio. I was getting a bit worried.
[17:55:43] <jlevon> heh
[17:58:16] <andy_js> Oh, and the file I’m reading is over 4GB in size.
[17:59:54] <rmustacc> Yeah. I was figuring it was at that intersection. I'm creating a little test program with a 1, 2, and 5 GB sparse file.
[18:00:05] <rmustacc> And creating something with 32-bit, lfs, and 64-bit. And will compare pre/post quickly.
[18:05:44] <rmustacc> andy_js: How are you seeking to the end in your program? With bits before that change I can't get fseek to seek to the end with lfs it seems.
[18:06:31] <andy_js> https://paste.ec/paste/Kbsiwuw8#my7wjt5ijS9nsO5ZYpdqKfBUBKJi+My-GyWoa6yQ8SA
[18:12:00] <rmustacc> So the irony is that before the memstream stuff I actually have the program fail entirely.
[18:14:23] <rmustacc> Oh, you're using ftello, not ftell.
[18:15:59] *** KeiraT <KeiraT!~k4ra@gateway/tor-sasl/k4ra> has quit IRC (Remote host closed the connection)
[18:16:16] <rmustacc> andy_js: I've reproduced that. Thanks for the pointer. I'll get that root caused shortly.
[18:16:58] *** KeiraT <KeiraT!~k4ra@gateway/tor-sasl/k4ra> has joined #illumos
[18:23:44] <rmustacc> andy_js: Got that root caused and a fix prototyped. There was a stagnant cast truncating the off64_t to a long.
[18:24:10] *** natkin <natkin!~textual@cpe-76-185-177-63.satx.res.rr.com> has joined #illumos
[18:24:12] <rmustacc> I've tested it on that sample file and will get a build kicked off and up for review once that's wrapped up. Thanks for reporting this and again, sorry for the breakage.
[18:26:17] *** jimklimov <jimklimov!~jimklimov@ip-86-49-254-26.net.upcbroadband.cz> has quit IRC (Quit: Leaving.)
[18:26:51] <andy_js> It might be worth adding some tests for the tell/seek stuff.
[18:27:04] <rmustacc> Agreed. Will do so as a follow up.
[18:27:11] <rmustacc> I did add a few there with the initial change.
[18:27:18] <rmustacc> But I want to get you unbroken first.
[18:27:41] <rmustacc> Unless you feel otherwise.
[18:28:46] <jlevon> oh yuck
[18:28:54] <rmustacc> It was a bad hold over with a cast.
[18:29:03] <rmustacc> From refactoring that and missing that edge condition.
[18:39:05] <rmustacc> andy_js, jlevon: https://code.illumos.org/c/illumos-gate/+/685 and linked ticket.
[18:39:21] <rmustacc> I'll go back and look at augmenting the test suite here.
[18:50:16] *** Kruppt <Kruppt!~Kruppt@50.111.31.166> has quit IRC (Quit: Leaving)
[18:57:57] *** fanta1 <fanta1!~fanta1@p200300f76bc408006c4dff792b220135.dip0.t-ipconnect.de> has quit IRC (Quit: fanta1)
[19:07:03] *** Kurlon_ <Kurlon_!~Kurlon@cpe-67-253-136-97.rochester.res.rr.com> has joined #illumos
[19:10:58] *** Kurlon <Kurlon!~Kurlon@167-48.gwi.net> has quit IRC (Ping timeout: 260 seconds)
[19:22:48] *** arnoldoree <arnoldoree!~arnoldore@113.210.177.165> has quit IRC (Quit: Leaving)
[19:29:11] <wonko> So, testing out some network performance here because I had questions about some things and some weird numbers coming back (that also explain what I was seeing)
[19:29:33] <wonko> two host. OmniOS and Windows 10. Both on 10G. Both with x520 cards.
[19:30:06] <wonko> Windows -> OmniOS is 1.7Gbit/s but from OmniOS -> Windows is 7Gbit/s
[19:30:42] <wonko> why such a discrepency? I've tested with a linux VM on the Triton cluster and saw a similar difference (although there topped out at under 5Gbit/s)
[19:36:48] <neuroserve> wonko : how did you test?
[19:37:14] <wonko> iperf3 just -s and -c so default options.
[19:40:20] *** Riastradh <Riastradh!~riastradh@netbsd/developer/riastradh> has quit IRC (Remote host closed the connection)
[19:40:43] *** Riastradh <Riastradh!~riastradh@netbsd/developer/riastradh> has joined #illumos
[19:41:53] <neuroserve> wonko : SFPs involved?
[19:42:13] <wonko> yes, all Cisco 10G SFPs
[19:45:40] *** Riastradh <Riastradh!~riastradh@netbsd/developer/riastradh> has quit IRC (Quit: leaving)
[19:46:09] *** Riastradh <Riastradh!~riastradh@netbsd/developer/riastradh> has joined #illumos
[20:10:01] *** Kurlon_ <Kurlon_!~Kurlon@cpe-67-253-136-97.rochester.res.rr.com> has quit IRC (Remote host closed the connection)
[20:10:37] *** Kurlon <Kurlon!~Kurlon@167-48.gwi.net> has joined #illumos
[20:24:14] *** hemi770 <hemi770!~hemi666@unaffiliated/hemi770> has quit IRC (Ping timeout: 256 seconds)
[20:31:04] <teutat3s[m]1> any pkgsrc gophers around? I've got a problem with LDFLAGS and correctly escaping / quoting them to make go happy
[20:35:10] *** am11 <am11!~am11@dsl-hkibng22-54f985-221.dhcp.inet.fi> has joined #illumos
[20:38:01] *** ptribble <ptribble!~ptribble@cpc92716-cmbg20-2-0-cust138.5-4.cable.virginm.net> has joined #illumos
[20:41:24] <am11> sjorge: an update, things are progressing on dotnet side of the house. a basic initialization is succeeding now. we are at the stage where we need to select one of the distros and create a rootfs environment for it on ubuntu to be able to cross-compile native+managed components in the form of `dotnet-runtime-5.0.0-preview.5.xxxxx.yy-illumos-x64.tar.gz`. without this --cross facility, it is (almost) a no-go.
[20:42:38] <rmustacc> am11: So illumos actually provides a bunch of functionality that we put together for that for rust.
[20:42:52] <rmustacc> am11: So maybe sync up with LeftWing on what you need?
[20:44:32] <am11> for instance, if we select smartos, the expectation is that we compile pkgsrc tools (pkgin etc.) as debian/linux binary, and when we execute `pkgin install blah`, it builds/fetches the package for smartos (and not debian/linux).
[20:45:12] <rmustacc> So we provide a sysroot for cross compiling rust.
[20:45:19] <rmustacc> I think you probably want to leverage that as much as you can.
[20:45:35] <am11> i just could not figure out how to point pkgin to smartos binaries repo (on ubuntu). :)
[20:45:50] <am11> +1, i will check it out.
[20:46:09] <rmustacc> You generally can't?
[20:46:41] <am11> i actually checked some scripts, for rust i think we only cross compile gcc? here we need 4 other dependencies. can be done in theory.
[20:47:44] <rmustacc> I don't really know. There's a bunch there, but I'd check with LeftWing and maybe pmooney. Since they've been doing that for rust. May at least be able to get you started in the right direction.
[20:48:24] <pmooney> am11: LeftWing and I created a sysroot tarball in order to facilitate cross-compiling rust from ubuntu
[20:48:51] <pmooney> It has the headers and libraries one would expect to be present in order to build for illumos
[20:49:10] <pmooney> at least the base system, that is
[20:49:49] <pmooney> this works for rust, since it's not linking to anything but the system libraries
[20:50:00] <pmooney> (it uses libcurl and openssl, but those are compiled in statically)
[20:51:11] <LeftWing> am11: Have a look at the archive we've put up at https://github.com/illumos/sysroot/releases
[20:51:35] <LeftWing> If you need more files than are in the archive, let us know! We can expand the contents we include there within reason
[20:53:20] <am11> pmooney: cool, could you please point me to the tarball? in addition to illumos-cross toolchain with headers, we need these packages in cross: cmake icu.
[20:53:46] <am11> ah just saw your message LeftWing :)
[20:53:51] <LeftWing> :D
[20:54:05] <pmooney> I assume the cmake would be built for the machine doing the building, not the cross target?
[20:54:27] <am11> pmooney: my bad, you are right.
[20:54:46] <am11> we would also need libcurl and openssl/libssl.
[20:55:05] <LeftWing> That will be more of a challenge, as distributions don't strictly agree on versions for those
[20:55:09] <pmooney> does the dotnet artifact link to libicu, libcur and openssl?
[20:55:35] <LeftWing> What do you do when cross-building for Linux?
[20:56:02] <am11> lttng-ust (although it compiles on solaris et al. based on their release notes), is not present in packages. i disabled tracing feature in dotnet for that reason.
[20:56:55] <LeftWing> Yeah we definitely don't have LTTng -- we have DTrace, and some other debugging and tracing facilities
[20:57:27] <am11> LeftWing: pmooney: they use a shim mechanism to support various versions of openssl, numa etc. whcih is feature detected on the runtime.
[20:58:21] <am11> e.g. https://github.com/dotnet/runtime/blob/54db4a39f86f07ca2a7d91c4620268d87ff324b2/src/libraries/Native/Unix/System.Security.Cryptography.Native/opensslshim.h
[20:58:22] *** Riastradh <Riastradh!~riastradh@netbsd/developer/riastradh> has quit IRC (Remote host closed the connection)
[20:58:31] <am11> and https://github.com/dotnet/runtime/blob/54db4a39f86f07ca2a7d91c4620268d87ff324b2/src/libraries/Native/Unix/System.Globalization.Native/pal_icushim.h
[20:58:46] <am11> and their accompanying .c files.
[20:58:58] *** Riastradh <Riastradh!~riastradh@netbsd/developer/riastradh> has joined #illumos
[20:59:19] <am11> so whichever version is available on runtime, it gets picked up.
[20:59:56] <am11> however, on the build machine, it is recomended that we should have headers for the latest version.
[21:00:18] <am11> (i think to capture debug symbols)
[21:04:12] <pmooney> well that's a bit terrifying
[21:04:18] <am11> on run time, these dotnet libraries will dlopen the binaries from LD_LIBRARY_PATH and friends,
[21:04:31] <LeftWing> That is both marvellous and scary all at once!
[21:04:54] <rmustacc> I gues if you dlsym everything you need you'll avoid the multiple address space problem... maybe.
[21:05:11] <LeftWing> rmustacc: Maybe?
[21:05:12] <pmooney> as for ABI....
[21:05:31] <LeftWing> rmustacc: Do we put the dlopened thing in a different link map of sorts?
[21:06:01] <LeftWing> Otherwise surely it might reach out and touch symbols that are already loaded, I would think, which could include global state of the wrong shape
[21:06:46] <rmustacc> LeftWing: Depends on how you access it. e.g. do you dlsym() everything you need or not.
[21:12:58] *** sjorge_be <sjorge_be!~sjorge@unaffiliated/sjorge> has joined #illumos
[21:15:30] *** sjorge <sjorge!~sjorge@unaffiliated/sjorge> has quit IRC (Ping timeout: 258 seconds)
[21:15:30] *** sjorge_be is now known as sjorge
[21:16:40] *** pwinder <pwinder!~pwinder@86.11.191.8> has quit IRC (Quit: This computer has gone to sleep)
[21:20:34] <LeftWing> rmustacc: But what if I dlsym() some function that itself needs some global state object
[21:20:53] <LeftWing> It doesn't presumably need to know it's being opened that way
[21:24:45] *** BOKALDO <BOKALDO!~BOKALDO@46.109.201.132> has quit IRC (Quit: Leaving)
[21:26:50] *** blackwood821 <blackwood821!~blackwood@c-174-49-16-176.hsd1.tn.comcast.net> has quit IRC ()
[21:27:37] *** ptribble <ptribble!~ptribble@cpc92716-cmbg20-2-0-cust138.5-4.cable.virginm.net> has quit IRC (Quit: Leaving)
[21:38:36] <richlowe> wha?
[21:48:34] *** phyre <phyre!~phyre___@78.30.22.107> has joined #illumos
[21:50:46] <sjorge> am11: sounds exciting
[21:51:33] <sjorge> Reusing the rust sysroot mentioned seems interesting too, that should make it distro independent!!
[21:53:55] <LeftWing> richlowe: "Wha?" to which part, specifically? :P
[21:54:39] <LeftWing> sjorge: Right, everything in there is from the base software in illumos-gate, and the exposed interfaces should be common to all distributions built from that or a later commit.
[21:54:52] <LeftWing> Except for the GCC/SSP runtime bits I guess
[21:54:59] <LeftWing> Which we checked are common to everything we could find
[21:55:31] <LeftWing> NOTE: If you operate a closed source distribution, and we can't see you, tautologically didn't look -- but whose fault is that!
[22:05:24] <sjorge> :)
[22:05:38] <sjorge> https://www.illumos.org/issues/12756 I assume this is not as easy as adding some id's to a driver file?
[22:06:15] <gitomat> [illumos-gate] 12757 lz4 hash table does not start zeroed -- Andy Fiddaman <omnios at citrus-it dot co.uk>
[22:07:10] <rmustacc> sjorge: The spec doesn't have the programming interface. Do you know if that's documented somewhere?
[22:20:07] <sjorge> rmustacc not sure, I can google around. I just have a new device that uses it and noticed it didn't drop a /dev/cua/N
[22:20:28] <sjorge> but both freebsd (rasberry pi) and rasbian seem to detect it OK
[22:21:38] <rmustacc> Right, we probably don't have a driver for it. It's just not clear what the expected USB programming interface is.
[22:21:49] <rmustacc> e.g. is it using a standard class device or is it its own thing.
[22:22:45] <jbk> do you know which driver it's using on fbsd?
[22:23:26] <rmustacc> jbk: It appears to be a device specific one that's linked from the ticket.
[22:24:07] <rmustacc> So that's why I was asking about the actual programming interface.
[22:24:21] <sjorge> Googling around just turns up a bunch of arduino stuff
[22:24:29] <sjorge> Seems a common device used to connect to them
[22:25:41] <rmustacc> I just feel better when the programming interface is actually documented and not just copying things.
[22:26:03] <sjorge> I think its a family of chips CH340 but there also seems to be a CH341
[22:27:10] <sjorge> I just keep finding the same PDF everyone, sometimes in chinese, sometimes english
[22:27:16] <sjorge> The one already in the ticket
[22:28:06] <jbk> 'the worst USB-serial chip in the world' heh
[22:28:29] <sjorge> I didn't chose the chip sadly
[22:28:37] <jbk> (from the fbsd source you pasted)
[22:28:45] <jbk> in the ticket
[22:28:49] <sjorge> that sounds very promising xD
[22:29:52] <sjorge> WCH seems to be hte manufacturer
[22:31:10] <sjorge> https://html.alldatasheet.com/html-pdf/1132618/ETC2/CH340G/110/1/CH340G.html this more useful?
[22:31:22] <sjorge> It's so far the first doc I found that is not the same as the one already linked
[22:34:00] <sjorge> which looks eerily similar
[22:34:27] <sjorge> hese magic numbers come from Linux (drivers/usb/serial/ch341.c), The manufacturer was unresponsive when asked for documentation. *face plants*
[22:35:18] <rmustacc> Sounds like someone will need to port / write a similar driver using those constants then.
[22:38:43] <sjorge> Ack, I'll need to look at a new rpi to forward it over tcp then. As it's sadly not a device where there are any alternatives. And writing a driver is not something in my skill set.
[22:39:11] <sjorge> Shall I close the ticket? Or leave it open?
[22:39:28] <sjorge> Well looks like I can't close it
[22:41:17] <rmustacc> No reason to close it.
[22:41:24] <rmustacc> Someone just needs to do the work.
[22:41:27] *** jamtorus <jamtorus!~quassel@45.83.220.175> has joined #illumos
[22:42:01] *** jellydonut <jellydonut!~quassel@45.83.220.175> has quit IRC (Read error: Connection reset by peer)
[22:44:29] <sjorge> interesting http://src.illumos.org/source/xref/illumos-gate/usr/src/uts/common/io/usb/usbdevs makes references to the chi[
[22:44:35] <sjorge> I wonder why it's not being detected
[22:44:55] <sjorge> Aha! looks like its the CH341SER not the CH340SER
[22:47:49] <sjorge> Let me reconnect the device
[22:48:31] <sjorge> same dmesg
[22:52:24] <sjorge> Hmmm, it is in the file! product WCH2 CH341SER 0x7523 CH341/CH340 USB-Serial Bridge
[22:52:29] <sjorge> I wonder why it's not recognized then
[22:52:56] <sjorge> I've updated the issue with the ::prtusb output
[22:53:10] <sjorge> idVender and idProduct seem to match
[22:54:03] <rmustacc> Because that file is just a list of all devices.
[22:54:08] <rmustacc> It's not about what's supported.
[22:54:12] <rmustacc> It's like the pci ids file.
[22:54:32] <sjorge> oh :(
[22:54:35] <sjorge> Thats disapointing
[22:55:09] <rmustacc> There's no way out without writing a driver.
[22:55:24] *** jamtorus is now known as jellydonut
[22:58:49] *** jamtorus <jamtorus!~quassel@45.83.220.175> has joined #illumos
[22:59:16] *** jellydonut <jellydonut!~quassel@45.83.220.175> has quit IRC (Disconnected by services)
[22:59:18] *** jamtorus is now known as jellydonut
[23:01:00] <LeftWing> But the good news is that a driver is just a C program!
[23:01:15] <LeftWing> You, too, can write one!
[23:01:36] <v_a_b> I have a serial PCIe card that's also not supported and the vendor even ships a Linux driver in C source.
[23:01:50] <jbk> there do appear to be a few examples of usb serial drivers in the gate
[23:01:53] <v_a_b> Guess who still hasn't figured out how to get this card to work in Illumos.
[23:02:03] <LeftWing> v_a_b: Is it you? :D
[23:02:05] <jbk> though we appear to require more code than the BSDs
[23:02:07] <v_a_b> BINGO
[23:02:17] <LeftWing> v_a_b: I imagine you'll need to write a driver
[23:02:26] <v_a_b> yep
[23:02:41] <v_a_b> That would be cool.
[23:02:52] * v_a_b slowly drifts away on the cloud...
[23:02:55] <LeftWing> lol
[23:03:05] <sjorge> clouds need drivers too
[23:03:19] <LeftWing> It's unlikely I'm going to be able to write it for you but if you're going to do it, we can always answer questions and help out as you hit roadblocks
[23:04:38] <v_a_b> I always wanted to write drivers...
[23:05:28] * sjorge notices multiple layers of abstraction we seem to have
[23:05:45] <sjorge> Seems to be a backend for usbser I guess
[23:05:49] <v_a_b> I once did write one when my brother bought an Olivetti typewriter with a Centronix interface with the data ready level inverted. So we had to flip a bit in the interface down when there was a new character to be typed.
[23:05:54] <sjorge> Which seems to have a whole... lot of bits having to do with termio
[23:06:04] <v_a_b> This was Z80 CP/M of course.
[23:06:15] <v_a_b> Illumos shouldn't be much different, right?
[23:07:19] *** gh34 <gh34!~textual@cpe-184-58-181-106.wi.res.rr.com> has quit IRC (Quit: Textual IRC Client: www.textualapp.com)
[23:08:13] * sjorge going to use a rpi with ser2net for now,
[23:08:30] <sjorge> Since it needs to be passed to zone anyway, this will also make it HA I guess as I can just move the zone then
[23:08:49] <LeftWing> As long as the Raspberry Pi isn't broken!
[23:09:14] <sjorge> There will always be a single point of failure as I can't have 2 of the devices
[23:09:37] <sjorge> So either a rPI or one of the two CN's will be the problem
[23:12:27] <LeftWing> Fair enough
[23:12:44] <LeftWing> For what it's worth, the layers of abstraction are there to help, btw
[23:12:57] <LeftWing> I believe a specific device would get a driver like usr/src/uts/common/io/usb/clients/usbser/usbftdi/usbser_uftdi.c
[23:13:50] <sjorge> Yeah, well I was looking at usbacm/usbacm.c and the freebsd one but don't really what the freebsd stuff is doing... which is probably step 1
[23:14:05] *** jamtorus <jamtorus!~quassel@45.83.220.175> has joined #illumos
[23:14:29] <LeftWing> Might help to compare something like usbsprl/pl2303_dsd.c (Prolific PL2303) instead
[23:14:30] *** jellydonut <jellydonut!~quassel@45.83.220.175> has quit IRC (Read error: Connection reset by peer)
[23:14:43] <LeftWing> err, usbsprl/usbser_pl2303.c
[23:15:04] <sjorge> whats does the _dsd.c and non _dsd.c difference? all seem to have both
[23:15:10] <sjorge> and _dsd.c is always huge
[23:15:22] <sjorge> Ah device-specific driver
[23:15:25] <LeftWing> https://code.illumos.org/plugins/gitiles/illumos-gate/+/master/usr/src/uts/common/io/usb/clients/usbser/usbsprl/usbser_pl2303.c
[23:15:36] <sjorge> So the dsd is the driver and the non dsd is the wrapper to fit that into usbser
[23:15:54] *** jellydonut <jellydonut!~quassel@45.83.220.175> has joined #illumos
[23:16:05] <LeftWing> Yeah it seems like that's the general split -- the bits to use usbser above, and then the device-specific bits to talk USB to the actual hardware below
[23:16:51] <LeftWing> Critically, usbser is providing a lot of the STREAMS stuff for you
[23:17:49] <LeftWing> https://code.illumos.org/plugins/gitiles/illumos-gate/+/master/usr/src/uts/common/io/usb/clients/usbser/usbsprl/pl2303_dsd.c#143 -- this ds_ops_t gets passed to the usbser framework
[23:18:35] *** liv3010m <liv3010m!~liv3010m@77-72-245-190.fibertel.com.ar> has quit IRC (Ping timeout: 265 seconds)
[23:18:48] <LeftWing> Which is described a bit in the header -- https://code.illumos.org/plugins/gitiles/illumos-gate/+/master/usr/src/uts/common/sys/usb/clients/usbser/usbser_dsdi.h
[23:18:49] <sjorge> I guess starting with that with all NULL and add bit by bit would be the way to tackle it
[23:19:19] *** jamtorus <jamtorus!~quassel@45.83.220.175> has quit IRC (Ping timeout: 246 seconds)
[23:20:57] *** liv3010m <liv3010m!~liv3010m@77-72-245-190.fibertel.com.ar> has joined #illumos
[23:38:45] *** andy_js <andy_js!~andy@94.11.185.123> has left #illumos
[23:50:44] <LeftWing> sjorge: Yeah I'd aim to get enough of the simple boilerplate together to have it attach and just do nothing
[23:50:52] <LeftWing> And then get a character to pop out, etc
[23:51:27] <LeftWing> And like I said, if you've got some of that together and you get stuck we can definitely help get you back on track
[23:51:35] *** hemi770 <hemi770!~hemi666@unaffiliated/hemi770> has joined #illumos
[23:52:07] <LeftWing> This is a good driver to work on as a first driver, though, I think -- you don't depend on it for disk or networking, so it's going to be relatively easy to debug
[23:54:25] <sjorge> I already have a list of 62 items to look up and I was only looking at the _attach function from openbsd :|
[23:54:55] <jbk> heh
[23:55:31] <sjorge> I'm just going to open a PR against the doc of the device that is does not work on illumos.
[23:55:41] <sjorge> So at least nobody else buys it
[23:57:35] <sjorge> Like the first thing I lost 10min on is... where is DS_OPS_VERSION defined
[23:57:45] <sjorge> src.illumos.org only lists usage not where it is defined
[23:58:27] *** jamtorus <jamtorus!~quassel@45.83.220.175> has joined #illumos
[23:58:51] <sjorge> also 'ds_ops_t' is defined twice but are different, but only one makes sense
[23:59:20] *** jamtorus2 <jamtorus2!~quassel@45.83.220.175> has joined #illumos
top

   May 20, 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 | >