Switch to DuckDuckGo Search
   April 12, 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:03:07] <hww3> if i call the pair in immediate succession, the device node isn't present, so it makes me wonder if something is altering the instance's dev_info_t in between... doesn't seem like that should be happening
[00:17:34] *** Woodstock <Woodstock!~grumpf@beiss.dessnourst.de> has quit IRC (Quit: ELVIS has left the building!)
[00:24:29] *** Woodstock <Woodstock!~grumpf@beiss.dessnourst.de> has joined #illumos
[00:35:03] <rmustacc> Assuming it's actually the same dip, no that's not expected behavior.
[00:36:12] <rmustacc> hww3: How are you trying to see if the device node is present or not? Are you looking in /devices, the kernel state elsewhere, or something else?
[00:44:28] <hww3> i'm using the dev_info_t * passed in to the xattach callback, which I keep. I'm looking in /devices.
[00:50:00] <hww3> the dev_info_t * is being passed into mac_register(), I wonder if mac is doing something that's causing a problem?.
[00:50:48] <rmustacc> No, it shouldn't.
[00:51:11] <rmustacc> But I guess the more relevant question is how are you checking that the minor is there or not.
[00:51:31] <rmustacc> In this case, you're probably creating a minor for /dev/iptun or something of that nature or?
[00:51:48] <rmustacc> That someone will ioctl and then in reponse you'll create an object with mac_register()?
[00:51:59] <rmustacc> And it's the minor for the control node that you're not seeing go away somehow?
[00:52:06] <hww3> so i'm basing my work on simnet
[00:52:29] <hww3> so i've got dladm ioctls registered to create and delete interfaces
[00:52:39] <rmustacc> OK. So what minor node are you creating?
[00:52:53] <hww3> and inside those create/delete ioctls, i am creating a character device node
[00:53:14] <hww3> i keep track of the minors I create in use
[00:53:36] <rmustacc> OK.
[00:53:46] <hww3> and it seems that i'm not overlapping with any being created by the dl/mac frameworks, but that could be a potential place to look
[00:54:05] <rmustacc> Well, I think I'll be able to better help and direct you if you can fill in a few more details.
[00:54:46] <rmustacc> e.g. answering my question about how you're checking that the minor still exists. Or understanding what the minor node is and if you've created any devfsadm plugins to try and map it into /dev or not.
[00:55:06] <hww3> i do have a devfsadm plugin that seems to be working properly
[00:55:19] <rmustacc> OK.
[00:55:22] <hww3> the mac minors seem to start at 1000
[00:55:57] <hww3> at least based on my reading of the header. i'm starting (somewhat arbitrarily) at zero.
[00:56:36] <rmustacc> Let me remind myself what I did in the overlay driver.
[00:57:10] <hww3> ddi_create_minor_node seems to happily create duplicate minors a long as the "name" portion differs, which is how I discovered there was something amiss
[00:58:01] <rmustacc> What are you passing for the m_instance value in the mac register state?
[00:59:20] <hww3> or rather (uint_i)-1
[00:59:40] <hww3> or rather (uint_t)-1 (please excuse the typos)
[01:00:59] <rmustacc> OK.
[01:01:22] <rmustacc> I assume this is a pseudo-device driver with a single instance?
[01:02:07] <hww3> yes, correct
[01:02:38] <rmustacc> So, I'd personally use kmdb and stop this in that context right before I called ddi_remove_minor_node and walk the dip devi_minor list.
[01:02:56] <rmustacc> And see what names are actually there before and after.
[01:04:02] <hww3> i was thinking that would probably be the next step if there wasn't something obvious, based on looking at ddi_remove_minor_node()
[01:05:11] <rmustacc> Unfortunately, there's not something immediately obvious from your case. It sounds like you're being careful about minor allocation and trying not to conflict with mac.
[01:05:51] <rmustacc> Are you doing a similar reference counting game that simnet is doing?
[01:06:20] <hww3> yes. i tried to keep as much of the existing simnet code as I could.
[01:06:42] <hww3> and that seems to be okay; the devices are actually being released.
[01:06:42] <rmustacc> Fair enough. I'm not sure I tried to model overlay that closesly on simnet.
[01:07:04] *** neirac <neirac!~neirac@pc-4-149-45-190.cm.vtr.net> has quit IRC (Ping timeout: 265 seconds)
[01:07:58] <rmustacc> But I also didn't have an additional per-device minor for the overlay driver.
[01:08:05] <hww3> my code tries to reuse minors so devices with low minor numbers are being left in /devices and newer ones created with the same minor.
[01:08:23] <rmustacc> I would recommend just using an id_space_t to track it, fwiw.
[01:08:37] <rmustacc> So you know what's allocated and what's not. So you don't have to reinvent tracking.
[01:08:45] <hww3> Yes, the extra minor for the userland data transfer has been a bit of a trick. I've learned a lot about STREAMS
[01:08:59] <hww3> Ah, thanks for that pointer. I will check it out.
[01:09:30] <rmustacc> You may also find the vnd driver I wrote a while ago somewhat useful for another more modern streams example.
[01:09:44] <rmustacc> But it's probably not how I would have designed what I was trying to solve today.
[01:09:59] <hww3> I found the third party tap/tun driver rather difficult to follow.
[01:10:12] <rmustacc> I've never really looked at it.
[01:10:43] <hww3> I have something that works for tightly controlled cases, this seems to be the major hang up at the moment.
[01:10:46] <rmustacc> And ar eyou doing ddi_remove_minor_node(dip, NULL) on purpose just to test the reuse issue?
[01:11:00] <rmustacc> OK, well if at some point you want another pair of eyes, let me know and I can try and look at something.
[01:12:29] <rmustacc> Aside from id reuse, is there anything else particular about the names or the cases here?
[01:12:31] <hww3> So removing the minor node is part of the regular use case so that when the pseudo device is removed using dladm, the "character device" node should also be removed.
[01:13:20] <rmustacc> Yes, that part makes sense. Just the use of the name of the minor versus NULL makes a difference. You mentioned you were passing the name as NULL, which is somewhat what surprised me here.
[01:13:36] <hww3> the names are supplied by dladm, so I end up with /devices/pseudo/feth\@0\:my1 for example.
[01:14:07] <hww3> Yes, I tried NULL when using the name of the link wasn't working properly. Seems the sledge-hammer didn't work either.
[01:14:32] <hww3> I will try to cozy up to mdb and see if i can figure out what's going wrong.
[01:15:37] <hww3> Thanks for your assistance; if I can get past these things on my own, I should be at a point where I can solicit some more design input... I'm sure I've made many a faux-pas.
[01:16:04] <rmustacc> Here's a one-liner to print all this data:
[01:16:07] <rmustacc> ::prtconf -d vioif | ::print struct dev_info devi_minor | ::list struct ddi_minor_data next | ::print struct ddi_minor_data
[01:16:18] <rmustacc> I used the vioif driver as an example, replace that with the name of your driver.
[01:17:23] <rmustacc> Actually, wait. If you're being given a name and you're creating the minor node based on that, how are you avoiding the fact that mac will create a minor of a different type with the same name?
[01:18:51] <hww3> so, i know that the observability node in /dev/net is being created, but I didn't see any others (aside from the one the driver is creating)
[01:19:49] <hww3> the mac nodes have minor numbers of 1000 + link_id; mine begin at zero
[01:19:51] <rmustacc> I need to remind myself how mac gets the names for those minors it's creating.
[01:20:04] <rmustacc> Sure, but two minors with the same name seems like a recipe for bad things.
[01:20:09] <rmustacc> Even if the actual numbers are different.
[01:20:37] <rmustacc> Because if you look at the impl of ddi_remove_minor_node() it doesn't actually care about the minor number and will remove the first thing with name that it expects.
[01:20:44] <rmustacc> Let me double check exactly what names mac is using in mac_register().
[01:21:47] <rmustacc> I guess it's all going to be based on driver and instance, so that should be fine.
[01:22:41] <hww3> i've disabled creation of that minor node and will see if by some odd chance i'm missing something
[01:24:06] <rmustacc> What type is the node you create on your own? S_IFCHR?
[01:24:21] <hww3> no nodes appear in /devices with the major or driver name
[01:24:23] <hww3> correct.
[01:25:21] <rmustacc> And what class are you using, out of curiosity?
[01:25:34] <rmustacc> Just pseudo?
[01:25:55] <hww3> yes
[01:26:19] <rmustacc> Well, this is quite odd. I guess use that mdb bit I used to maybe dig and we can use that to go from there.
[01:26:27] <rmustacc> Alternatively, if you want to share the code, I can take a poke at it at some point.
[01:28:32] <rmustacc> Let me know what you find. Having a first class zone-aware iptun/tap driver will be exciting!
[01:28:58] <hww3> Yes, of course... I'll get it pushed somewhere this evening if you want to have a look, and I'll also dig in with mdb a bit more.
[01:29:41] <hww3> and thanks for walking through some of this with me.
[01:30:49] <rmustacc> Sure, no problem. Happy to help.
[01:31:06] <rmustacc> Don't hesitate to reach out if you have additional questions.
[02:16:57] <hww3> ::bp feth`i_feth_delete
[02:17:54] <hww3> well, i suppose that's both the wrong syntax and wrong tool
[02:19:42] *** neirac <neirac!~neirac@pc-4-149-45-190.cm.vtr.net> has joined #illumos
[02:39:53] *** arekinath <arekinath!~arekinath@pdpc/supporter/professional/arekinath> has quit IRC (Ping timeout: 245 seconds)
[02:41:03] *** melloc1 <melloc1!~codytimec@104.166.94.34> has quit IRC (Ping timeout: 250 seconds)
[02:41:03] *** jordan[m]11 <jordan[m]11!~jordantim@104.166.94.34> has quit IRC (Ping timeout: 250 seconds)
[02:41:07] *** arekinath <arekinath!~arekinath@pdpc/supporter/professional/arekinath> has joined #illumos
[02:41:47] *** jordan[m]11 <jordan[m]11!~jordantim@104.166.94.34> has joined #illumos
[02:41:59] *** melloc1 <melloc1!~codytimec@104.166.94.34> has joined #illumos
[02:55:53] <richlowe> it's the right syntax for mdb, but a breakpoint in the kernel will require you being on the console and with kmdb (mdb -K)
[02:59:54] <hww3> richlowe: thanks- I mixed the upper-case K. Also taking the opportunity to hook up the serial console to my dev vm.
[03:22:53] *** varna_ <varna_!~varna@36.24.136.167> has joined #illumos
[03:23:08] *** varna <varna!~varna@36.24.139.29> has quit IRC (Read error: Connection reset by peer)
[03:23:28] *** KindOne <KindOne!root@freenode/father-christmas/kindone> has joined #illumos
[03:37:45] *** jcea <jcea!~Thunderbi@2001:bc8:2ecd:caed:7670:6e00:7670:6e00> has quit IRC (Quit: jcea)
[04:01:37] *** neirac <neirac!~neirac@pc-4-149-45-190.cm.vtr.net> has quit IRC (Quit: Lost terminal)
[04:44:33] *** arnoldoree <arnoldoree!~arnoldore@2001:d08:1a83:2563:793:e522:b452:8ee9> has joined #illumos
[06:01:02] *** varna_ <varna_!~varna@36.24.136.167> has quit IRC (Ping timeout: 256 seconds)
[06:01:21] *** varna <varna!~varna@36.24.136.167> has joined #illumos
[07:00:37] *** varna <varna!~varna@36.24.136.167> has quit IRC (Ping timeout: 250 seconds)
[07:00:53] *** varna <varna!~varna@36.24.136.167> has joined #illumos
[07:21:46] *** BOKALDO <BOKALDO!~BOKALDO@91.105.118.93> has joined #illumos
[08:00:54] *** varna <varna!~varna@36.24.136.167> has quit IRC (Ping timeout: 240 seconds)
[08:48:55] *** alanc <alanc!~alanc@inet-hqmc01-o.oracle.com> has quit IRC (Remote host closed the connection)
[08:49:22] *** alanc <alanc!~alanc@inet-hqmc01-o.oracle.com> has joined #illumos
[09:06:32] *** lblume <lblume!~lblume@greenviolet/laoyijiehe/lblume> has quit IRC (Ping timeout: 265 seconds)
[09:18:51] *** phyre__ <phyre__!~phyre___@78.30.20.36> has joined #illumos
[11:09:05] *** leoric <leoric!~leoric@2a02:2698:602b:4d2:219:d1ff:fe24:19b3> has joined #illumos
[11:09:19] <leoric> one thing which irritates me in smf - https://www.illumos.org/issues/12509
[11:37:01] *** tsoome <tsoome!~tsoome@91.209.240.229> has quit IRC (Read error: Connection reset by peer)
[11:37:07] <v_a_b> leoric I don't really understand the point. The runtime directory can easily be created by the start method. It is much more flexible than an SMF property.
[11:37:26] <v_a_b> And you don't need a "su application user" script because you can set the user context in the manifest.
[11:37:50] *** tsoome <tsoome!~tsoome@91.209.240.229> has joined #illumos
[11:38:02] <leoric> you can't set user context in manifest, if you create runtime directory in script
[11:38:14] <leoric> drwxr-xr-x 9 root sys 1791 Apr 10 09:25 /var/run
[11:38:53] <v_a_b> Ah, you don't have the sticky bit on /var/run. Is that standard OI, or have you changed that?
[11:39:10] <leoric> it's standard
[11:40:05] <v_a_b> Yep, see it on my OmniOS. Now I understand your point better. The startup method would need to run under root, do the mkdir, and then su to the app user. Got it.
[11:40:12] <leoric> usr/src/pkg/manifests/SUNWcs.mf:dir path=var/run group=sys
[11:40:22] *** arnoldoree <arnoldoree!~arnoldore@2001:d08:1a83:2563:793:e522:b452:8ee9> has quit IRC (Ping timeout: 260 seconds)
[11:56:05] *** arnoldoree <arnoldoree!~arnoldore@2001:d08:1009:5341:38b7:3173:8830:f523> has joined #illumos
[12:06:42] <toastersonerson1> leoric (IRC): +1 on that issue. would be a very nice fature to have
[12:22:54] *** ovi <ovi!~sh42@178.251.69.48> has quit IRC (Ping timeout: 256 seconds)
[12:26:22] *** jenelizabeth <jenelizabeth!~jenelizab@cpc155793-brmb11-2-0-cust474.1-3.cable.virginm.net> has quit IRC (Ping timeout: 256 seconds)
[12:35:52] *** wacki <wacki!~wacki@i577B85F8.versanet.de> has joined #illumos
[12:48:52] *** schily <schily!~joerg@p4FD0BCD1.dip0.t-ipconnect.de> has joined #illumos
[12:50:42] *** ovi <ovi!~sh42@178.251.69.48> has joined #illumos
[12:54:47] *** amrfrsh <amrfrsh!~Thunderbi@134.19.189.92> has quit IRC (Quit: amrfrsh)
[13:00:14] <andyf> leoric - yes, it would be nice :) I also want a periodic startd thing as I have grown used to it with Solaris packages
[13:00:42] <toastersonerson1> periodic startd?
[13:06:46] *** nbhauke <nbhauke!~hauke@55d4640e.access.ecotel.net> has joined #illumos
[13:08:26] *** leoric <leoric!~leoric@2a02:2698:602b:4d2:219:d1ff:fe24:19b3> has quit IRC (Ping timeout: 246 seconds)
[13:15:29] <andyf> https://docs.oracle.com/cd/E88353_01/html/E72487/svc.periodicd-8.html
[13:17:01] <andyf> It saves having to add methods just to add cron jobs for packages that need them
[13:21:51] <toastersonerson1> ah like timerd from systemd
[13:27:10] *** tsoome <tsoome!~tsoome@91.209.240.229> has quit IRC (Read error: Connection reset by peer)
[13:28:07] *** tsoome <tsoome!~tsoome@91.209.240.229> has joined #illumos
[13:33:13] *** amrfrsh <amrfrsh!~Thunderbi@134.19.189.92> has joined #illumos
[13:35:55] *** nbhauke <nbhauke!~hauke@55d4640e.access.ecotel.net> has quit IRC (Quit: nbhauke)
[13:51:02] *** arnoldoree <arnoldoree!~arnoldore@2001:d08:1009:5341:38b7:3173:8830:f523> has quit IRC (Ping timeout: 260 seconds)
[14:03:35] *** arnoldoree <arnoldoree!~arnoldore@2001:d08:1030:68c0:5248:2983:b4f6:3d16> has joined #illumos
[14:05:41] *** lgtaube <lgtaube!~lgt@213-67-21-71-no84.tbcn.telia.com> has quit IRC (Read error: Connection reset by peer)
[14:06:59] *** nbhauke <nbhauke!~hauke@55d4640e.access.ecotel.net> has joined #illumos
[14:09:50] *** lgtaube <lgtaube!~lgt@213-67-21-71-no84.tbcn.telia.com> has joined #illumos
[14:13:04] *** BOKALDO <BOKALDO!~BOKALDO@91.105.118.93> has quit IRC (Quit: Leaving)
[14:14:57] <wilbury> fwiw, recent illumos-nightly runs well in bhyve in freebsd
[14:27:44] *** schily <schily!~joerg@p4FD0BCD1.dip0.t-ipconnect.de> has quit IRC (Quit: BitchX-1.0c19 -- just do it.)
[14:30:53] *** varna <varna!~varna@36.24.136.167> has joined #illumos
[14:43:14] <sjorge> jbk / LeftWing I got it working with the sysconf call... boy I spend 20 minutes reading up on memory allocation because I had to do it... doing some functional tests now
[14:43:24] <sjorge> I might still have done it wrong though, the memory stuff
[14:46:18] <andyf> sjorge - nope :)
[14:46:48] <sjorge> andyf ? I haven't pushe the new code yet ?
[14:46:53] <sjorge> Or are you assume I got it wrong :p
[14:47:03] <sjorge> because that is just my assumption too after reading up on it
[14:47:23] <andyf> you're right, bhyve VMs use their own memory arena
[14:47:35] <sjorge> Ah for #smartos :)
[14:47:39] <sjorge> I was confused
[14:47:40] <andyf> oh dear
[14:47:43] <andyf> sorry, my fault
[14:47:58] <andyf> I confused both conversations.. I'll go and get some more coffee
[14:48:09] <sjorge> trying to get pam_list to accept %groupname in allow=/deny= files :D
[14:48:12] <sjorge> Well I got it working I think
[14:48:28] <sjorge> But after some suggestions from jbk I switched to sysconf to get a value and it required memory allocation :D
[14:48:36] <sjorge> And yes, more coffee!
[14:59:14] *** jcea <jcea!~Thunderbi@2001:bc8:2ecd:caed:7670:6e00:7670:6e00> has joined #illumos
[15:01:14] *** ldepandis <ldepandis!~ldepandis@unaffiliated/ldepandis> has joined #illumos
[15:01:51] *** nbhauke <nbhauke!~hauke@55d4640e.access.ecotel.net> has quit IRC (Quit: nbhauke)
[15:17:40] *** BOKALDO <BOKALDO!~BOKALDO@91.105.118.93> has joined #illumos
[15:29:22] *** schily <schily!~joerg@p4FD0BCD1.dip0.t-ipconnect.de> has joined #illumos
[15:32:43] *** jellydonut <jellydonut!~quassel@s91904423.blix.com> has quit IRC (Quit: jellydonut)
[15:38:38] *** Kruppt <Kruppt!~Kruppt@50-111-59-169.drhm.nc.frontiernet.net> has joined #illumos
[15:41:47] <sjorge> jbk / LeftWing all still works, even fixed my pam.conf so it also reject ssh logins https://github.com/joyent/illumos-joyent/compare/master...sjorge:pam_list?expand=1
[15:44:44] *** jcea <jcea!~Thunderbi@2001:bc8:2ecd:caed:7670:6e00:7670:6e00> has quit IRC (Remote host closed the connection)
[15:47:54] *** jellydonut <jellydonut!~quassel@s91904423.blix.com> has joined #illumos
[15:54:33] *** jcea <jcea!~Thunderbi@2001:bc8:2ecd:caed:7670:6e00:7670:6e00> has joined #illumos
[16:12:12] *** tsoome <tsoome!~tsoome@91.209.240.229> has quit IRC (Read error: Connection reset by peer)
[16:14:17] *** tsoome <tsoome!~tsoome@91.209.240.229> has joined #illumos
[16:19:44] *** am11 <am11!54f985dd@dsl-hkibng22-54f985-221.dhcp.inet.fi> has joined #illumos
[16:26:23] <am11> jbk: thanks a lot for the unwind fixes! i left a comment about my findings on smartos. i guess i would need crt1.o fixes?
[16:29:42] *** arnoldoree <arnoldoree!~arnoldore@2001:d08:1030:68c0:5248:2983:b4f6:3d16> has quit IRC (Ping timeout: 260 seconds)
[16:32:30] <am11> also i send a pr for dotnet base class library (only native parts for now): https://github.com/dotnet/runtime/pull/34867. not sure if i get the fs magic numbers right, i couldn't find all of them. would appreciate if you could take a look. :)
[16:33:06] <am11> build command for that is: `cd dotnet-runtime; ./src/libraries/Native/build-native.sh -gcc -skipgenerateversion`
[16:35:17] *** varna <varna!~varna@36.24.136.167> has quit IRC (Ping timeout: 256 seconds)
[16:35:37] *** varna <varna!~varna@60.176.146.221> has joined #illumos
[16:42:12] *** arnoldoree <arnoldoree!~arnoldore@2001:d08:2081:bc43:d9c3:a9cc:e44a:1ddd> has joined #illumos
[16:50:22] *** Teknix <Teknix!~pds@69.41.134.110> has quit IRC (Ping timeout: 265 seconds)
[16:56:11] <tomww> win 21
[16:57:11] *** idodeclare <idodeclare!~textual@cpe-76-185-177-63.satx.res.rr.com> has quit IRC (Quit: Textual IRC Client: www.textualapp.com)
[16:59:26] *** wacki <wacki!~wacki@i577B85F8.versanet.de> has quit IRC (Ping timeout: 256 seconds)
[16:59:55] *** wacki <wacki!~wacki@i577B85F8.versanet.de> has joined #illumos
[17:13:14] *** idodeclare <idodeclare!~textual@cpe-76-185-177-63.satx.res.rr.com> has joined #illumos
[17:19:05] <andyf> @LeftWing - I just tried changing one my bhyve VMs to use nvme for the disk interface.. not really expecting great results
[17:19:38] <andyf> @LeftWing - it actually worked, and your new ZFS path change code got some exercise
[17:19:39] <andyf> https://paste.ec/paste/VbEnLDlD#tVSjP6aHdKWvNumT1Uk7yG6-QH3xB9U8dAG0nJnjZFS
[17:19:58] <andyf> I have no idea if the bhyve nvme emulation is better than the vioblk one; I was just experimenting
[17:20:49] *** idodeclare <idodeclare!~textual@cpe-76-185-177-63.satx.res.rr.com> has quit IRC (Quit: Textual IRC Client: www.textualapp.com)
[17:21:26] *** idodeclare <idodeclare!~textual@cpe-76-185-177-63.satx.res.rr.com> has joined #illumos
[17:25:37] <LeftWing> andyf: Neat!
[17:27:13] <LeftWing> andyf: So that'll be in the upcoming stable?
[17:28:58] *** varna <varna!~varna@60.176.146.221> has quit IRC (Ping timeout: 256 seconds)
[17:29:15] *** varna <varna!~varna@60.176.146.221> has joined #illumos
[17:29:17] *** nbhauke <nbhauke!~hauke@55d4640e.access.ecotel.net> has joined #illumos
[17:34:37] <rmustacc> leoric, andyf: If you all have more formal thoughts on the semantics (e.g. perms, etc.) of the things like the create directory or timer pieces in startd, let me know. I might be up for poking at it.
[18:01:44] *** nbhauke <nbhauke!~hauke@55d4640e.access.ecotel.net> has quit IRC (Quit: nbhauke)
[18:03:25] <sjorge> andyf: nvme works with your nvme firmware
[18:03:45] <sjorge> Not with the older firmware on SmartOS, that one only works in windows for some reason
[18:08:07] *** arnoldoree <arnoldoree!~arnoldore@2001:d08:2081:bc43:d9c3:a9cc:e44a:1ddd> has quit IRC (Remote host closed the connection)
[18:23:15] <LeftWing> There have probably been a number of improvements in the firmware over time
[18:23:20] <LeftWing> on the FreeBSD side
[18:26:48] *** neirac <neirac!~neirac@pc-4-149-45-190.cm.vtr.net> has joined #illumos
[18:29:53] <neirac> Smithx10 take a look at https://github.com/cneira/nomad/tree/illumos , the ui I cannot build the web ui errors out on babel
[18:41:22] *** Kruppt <Kruppt!~Kruppt@50-111-59-169.drhm.nc.frontiernet.net> has quit IRC (Quit: Leaving)
[18:50:25] *** nbhauke <nbhauke!~hauke@55d4640e.access.ecotel.net> has joined #illumos
[18:51:22] *** igork <igork!~igork@91.204.56.74> has quit IRC (Quit: Leaving.)
[19:04:20] <sjorge> LeftWing yeah, someone is trying to upstream all the bhyve stuff now and I've been testing that. WIth that firmware vnc and nvme works in windows, freebsd and illumos guests too
[19:04:34] <sjorge> But it breaks a few other things like cpu topologies and console fonts
[19:04:56] <sjorge> e.g. windows only enables 1 vcpu but does see the toplogy of socket=1,cores=2,threads=2
[19:05:04] <sjorge> Trying to test illumos as much as I can :)
[19:05:15] <sjorge> Makes it easier to switch once it's all upstream in ed2k
[19:05:26] <LeftWing> That's terrific
[19:05:56] <andyf> Back from gardening duty...
[19:06:02] <andyf> @LeftWing - yes, it's in r151034
[19:06:14] <LeftWing> When will that be out?
[19:06:30] <andyf> First monday in May is the scheduled date
[19:06:37] <LeftWing> Cool
[19:06:55] <LeftWing> I look forward to making new VM images haha
[19:06:59] <LeftWing> It'll be so much easier
[19:07:04] <andyf> Well you've made it easier :)
[19:08:11] <LeftWing> If I polish up the DigitalOcean metadata agent I wrote, do you want to make DO images a thing?
[19:08:19] <LeftWing> They'll accept a URL at least
[19:08:29] <LeftWing> Of a disk image to download and import
[19:08:43] <LeftWing> So we could make an OmniOS project official one
[19:09:09] <andyf> @rmustacc - oh, excellent. The timer stuff in Solaris is based on a new restarter, svc.periodicd rather than svc.startd - I don't know if it's possible to use the same schema as Solaris for those - it would make it easier for people who package for both (like me!)
[19:09:30] <andyf> @LeftWing - Yes, that would be nice. We never did get the Azure ones into the marketplace
[19:09:33] <LeftWing> If the schema is sensible it doesn't seem like a bad place to start
[19:10:17] <andyf> SMF already supports multiple restarters, I've just never dug into what would be required to write a new one to plug in
[19:10:57] <LeftWing> There's the inetd one to look at I guess
[19:11:06] <andyf> ah right, I knew there were two
[19:12:02] <andyf> @sjorge - FWIW, making the single boot disk nvme worked but had awful performance
[19:12:36] <andyf> That's with the Intel chap's firmware - edk2-stable201903
[19:12:48] <andyf> I haven't tried Bex's yet on omnios
[19:15:43] <hww3> @rmustacc: I dug into the device minor list as you suggesed and everything seemed correct in terms of what ddi_remove_minor_node() was doing.
[19:16:12] <hww3> so I dug around a bit more in sunddi.c and devfsadm/* and began to think the problem might be devfs caching codes
[19:16:44] <hww3> which is when I discovered devfs_clean() and calling that after removing the minor nodes solved the problem
[19:16:55] <toastersonerson1> LeftWing (IRC): we should think about cloud-init at some point so we can support all major cloud providers
[19:17:30] <LeftWing> You're welcome to work on cloud-init but I'm not going to do that myself
[19:17:36] <LeftWing> It's a giant mess of a thing
[19:18:16] <toastersonerson1> Yeah I feared. I have to implement a lot of the providers myself aswell... let's see what the most sensible path will be when I get to it.
[19:19:55] <hww3> s/devfs caching codes/devfs caching nodes
[19:24:01] *** schily <schily!~joerg@p4FD0BCD1.dip0.t-ipconnect.de> has quit IRC (Quit: BitchX-1.0c19 -- just do it.)
[19:24:21] <rmustacc> hww3: Ah, ok. I suspect that in the normal context of attach/detach they do that for you.
[19:25:26] <hww3> @rmustacc: yes, I believe so, at least during a modunload. since this driver doesn't detach in normal operation, that cleanup never happens.
[19:26:43] <hww3> also, id_space_t was a big help. i don't think i'd have stumbled upon it on my own.
[19:27:13] <neirac> toasterson, LeftWing cloud-init would be awesome
[19:27:41] <rmustacc> hww3: If it helps, you may want to look at the overlay driver I wrote (in illumos-joyent).
[19:27:48] <rmustacc> Just for similar ideas like that.
[19:28:13] <Smithx10> LeftWing: I looked at clout-init 1 time.... and immediately stopped lol
[19:28:37] <hww3> @rmustacc: I actually started looking through it this morning. It's been very informative.
[19:29:37] <hww3> toasterson1, nierac: I looked into adding illumos support to cloud-init. in theory the basics aren't too bad but cloud-init tries to boil the ocean and i quickly lost interest.
[19:30:01] <toastersonerson1> yeah I probably will have to make a go libarary to parse the configs and issue the commands
[19:30:13] <hww3> I ended up taking parts of the smartdc tools for bsd and combined them with some of joyent's smf material.
[19:31:09] <hww3> perhaps it would be possible to make that more general for other cloud providers? the mdata-client joyent uses for its integration has a pretty straightforward interface.
[19:34:11] <sjorge> andyf vioblk > ahci > nvme for performance for me on windows
[19:34:18] <sjorge> also vioblk has unmap now
[19:34:30] <hww3> My nodes all run on triton or bare metal so I didn't really need to abstract things further, but that could be an interesting little project.
[19:34:57] <sjorge> andyf bex firmware is definately better than the intel blokes, you need to use bhyve_code.fd, the merged one didn't work
[19:35:14] <neirac> hww3 yes, would be nice to deploy omnios with cloud-init
[19:35:19] <sjorge> she's looking into the vcpu toplogy bug I am hitting on windows and the console font being messed up
[19:35:25] <hww3> https://git.sr.ht/~hww3/oi-vm-tools/ <-- my notes and the scripts I collected from various of joyent's materials.
[19:37:54] *** tsoome <tsoome!~tsoome@91.209.240.229> has quit IRC (Read error: Connection reset by peer)
[19:38:39] <neirac> hww3 thanks for sharing!
[19:39:50] *** tsoome <tsoome!~tsoome@91.209.240.229> has joined #illumos
[19:42:19] <hww3> neirac: no problem. i don't know whether the approach i took is better or worse than cloud-init. i think the scope of cloud-init is quite large so supporting illumos could mean a lot of things.
[19:42:59] <hww3> if anyone's interested in helping me make the scripts i cobbled together work better for multi-cloud, i'm certainly game for it
[20:10:49] *** Qatz <Qatz!~db@2601:187:8400:5::c92> has quit IRC (Read error: Connection reset by peer)
[20:11:24] *** Qatz <Qatz!~db@2601:187:8400:5::c92> has joined #illumos
[20:29:47] <toastersonerson1> Has anybody ever tried to run a meteor app on an illumos distro?
[20:43:26] <neirac> in mdb how do I set a breakpoint on a function ?
[20:47:40] *** BOKALDO <BOKALDO!~BOKALDO@91.105.118.93> has quit IRC (Quit: Leaving)
[20:50:47] *** nbhauke <nbhauke!~hauke@55d4640e.access.ecotel.net> has quit IRC (Quit: nbhauke)
[20:55:10] *** neirac <neirac!~neirac@pc-4-149-45-190.cm.vtr.net> has quit IRC (Ping timeout: 256 seconds)
[20:58:56] *** tsoome <tsoome!~tsoome@91.209.240.229> has quit IRC (Read error: Connection reset by peer)
[20:59:58] *** tsoome <tsoome!~tsoome@91.209.240.229> has joined #illumos
[21:08:06] *** merzo__ <merzo__!~merzo@153-21-133-95.pool.ukrtel.net> has joined #illumos
[21:10:41] *** merzo_ <merzo_!~merzo@122-23-132-95.pool.ukrtel.net> has quit IRC (Ping timeout: 256 seconds)
[21:30:11] *** nbhauke <nbhauke!~hauke@55d4640e.access.ecotel.net> has joined #illumos
[21:31:29] <LeftWing> https://github.com/illumos/illumos-gate/blob/4e0c5eff9af325c80994e9527b7cb8b3a1ffd1d4/usr/src/cmd/prtvtoc/prtvtoc.c#L262-L263
[21:31:32] <LeftWing> Well that can't be right
[21:44:13] <toastersonerson1> LeftWing (IRC): It could it is a way to check if a string start with /dev/ acording to manpage
[21:45:07] <toastersonerson1> although /dev/ without anything else could fail. it's a complicated entry in the manpage
[21:45:22] <LeftWing> I think the parenthesis is in the wrong place
[21:45:55] <LeftWing> It's effectively using `strlen("/dev/") != 0` as the length
[21:46:15] <LeftWing> Which will always be true, and thus 1 character?
[21:46:26] <toastersonerson1> Yep they are
[21:48:49] <toastersonerson1> although does C have thruthy? like 0 counts as false. then it would still work.
[21:56:34] *** neirac <neirac!~neirac@pc-4-149-45-190.cm.vtr.net> has joined #illumos
[22:24:56] *** nbhauke <nbhauke!~hauke@55d4640e.access.ecotel.net> has quit IRC (Quit: nbhauke)
[22:29:32] *** nikolam <nikolam!~Nikolam@unaffiliated/nikolam> has joined #illumos
[22:32:38] *** wacki <wacki!~wacki@i577B85F8.versanet.de> has quit IRC (Quit: Lingo: www.lingoirc.com)
[22:41:39] <rzezeski> neirac: mdb cannot set breakpoints, it can only observe the running kernel. To set a breakpoint you need to drop into kmdb (`mdb -K`). Once in kmdb you can use `:b` or `::bp` (e.g. `function_name:b`. You can also set a BP from outside of kmdb by using `dtrace -w` and the destructive action `breakpoint()`. When that trips you'll be dropped into kmdb.
[22:43:29] *** ypankov <ypankov!~ypankov@85.174.192.114> has joined #illumos
[22:44:26] <LeftWing> If you're pointing mdb at a process though, it can set breakpoints in that
[22:49:30] *** Teknix <Teknix!~pds@69.41.134.110> has joined #illumos
[22:50:53] *** nikolam <nikolam!~Nikolam@unaffiliated/nikolam> has quit IRC (Quit: Leaving)
[22:50:55] *** neirac <neirac!~neirac@pc-4-149-45-190.cm.vtr.net> has quit IRC (Ping timeout: 250 seconds)
[22:58:37] *** am11 <am11!54f985dd@dsl-hkibng22-54f985-221.dhcp.inet.fi> has quit IRC (Remote host closed the connection)
[23:26:55] <wilbury> i just got "WARNING: vioblk0: DMA handle allocation failed (ffffffff)". where to look? OI hipster in bhyve, host system kinda loaded
[23:27:14] <wilbury> panic with "I/O to pool 'rpool' appears to be hung." followed
[23:28:14] *** clapont <clapont!~clapont@unaffiliated/clapont> has quit IRC (Ping timeout: 240 seconds)
[23:43:16] <LeftWing> wilbury: Did you happen to get a dump?
[23:43:22] <wilbury> LeftWing: yes, i'll post
[23:44:32] *** phyre__ <phyre__!~phyre___@78.30.20.36> has quit IRC (Remote host closed the connection)
[23:44:59] <wilbury> i was rebuilding oi-hipster userland in that vm, while doing poudriere crosscompile world for aarch64 arch. host system is 8core, 64G ram, fast disks.
[23:45:22] <wilbury> while doing poudriere in another vm
[23:45:34] <LeftWing> So you're presumably here: https://github.com/illumos/illumos-gate/blob/63878f749f68d1c188363e0e7a36e7b7e855dff2/usr/src/uts/common/io/virtio/virtio_dma.c#L106-L110
[23:47:44] <LeftWing> Though I'm a bit unclear on how that happened unless it was at boot
[23:47:53] <wilbury> http://freebsd-stable.builder.wilbury.net/patches/otis/oi1.txt
[23:48:16] <wilbury> msgbuf
[23:48:42] <LeftWing> Yeah that stack doesn't really help, because the deadman only fires well after the problem happened somewhere else generally
[23:49:11] <wilbury> ok, let me upload whole vmdump
[23:50:55] <wilbury> http://freebsd-stable.builder.wilbury.net/patches/otis/vmdump.0
[23:53:56] <wilbury> and yes, i run master with debug there
[23:55:00] <LeftWing> wilbury: Can you give me the MD5 hash
[23:55:08] <LeftWing> So that I can make sure my download works
[23:55:42] <wilbury> 252459a884342e9d0bd6a0834ea66fa3
[23:55:58] <LeftWing> Tah. Should have it in ~10 minutes
[23:59:14] <ypankov> LeftWing: looks like we can get there via virtio_dma_alloc_nomem() as well
[23:59:33] <wilbury> so probably not only my pebkac :-P
[23:59:51] <LeftWing> ypankov: Yes, I would expect that log message to come from either of the virtio_dma_alloc*() functions
top

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