01:22:21 <jclulow> There are a lot of probably cheaper machines that will be much better for a home lab setup, FWIW
01:23:21 <jclulow> mid 2010s Dell and Lenovo small form factor systems are quite cheap, and you can usually find one with a proper physical serial port which is much better than a framebuffer console
02:28:04 <jbk> doh! how did i miss that tab :(
13:33:15 <elwisp> rmustacc: you hade suggestions as you were leaving?
13:33:32 <elwisp> regarding propolis rebooting the host
14:47:24 <rmustacc> Well, if it is, that should generally create a kernel crash dump. So I would verify you have a dump device set up in dumpadm.
15:49:55 <jbk> one of these days, i'm going to spend a week or two documenting all the various APIs and such surrounding the device tree... (as I dig into what looks like a use-after-free issue with multipath devices)
16:21:18 <rmustacc> Is there something specifically you're looking for we could help with?
16:22:16 <jbk> just that most of it's undocumented
16:22:44 <jbk> so at least whenever i'm dealing with it, it always feels like i'm just cargo culting other code without feeling fully confident I know i'm doing the right thing
16:22:45 <rmustacc> I get that. Was just trying to see if I could help share knowledge or something in the interim.
16:24:09 <rmustacc> Even knowing what specifically you're looking for better docs for. Just saying others can help potentially.
20:03:36 <jbk> one thing that'd be useful is for devices (and specifically mdi devices in this case, but it's been a general thing), there are a number of states and just what exactly the expectations/guarantees are for each.. i mean the names imply some stuff, but it seems like there's often some not as obvious implications
20:03:53 <jbk> (sorry.. been jumping around from multiple things)
21:02:40 <tsoome> jclulow do you want to speak about this call: https://src.illumos.org/source/xref/illumos-gate/usr/src/uts/common/io/virtio/virtio_main.c?r=64439ec0&mo=4578&fi=181#197 ?:)
22:08:35 <gitomat> [illumos-gate] 16024 bofi(4D) should not use sparc specific headers on intel -- Richard Lowe <richlowe⊙rn>
22:08:35 <gitomat> [illumos-gate] 16025 nxge(4D) shouldn't look for sparc specific headers -- Richard Lowe <richlowe⊙rn>
23:48:41 <jbk> i know sometimes order matters when building stuff, but for ld's -z assert-deflib, if -L/path -L/path2... come after, should it still be ok?
23:50:47 <rmustacc> The -z assert-deflib placement shouldn't matter.
23:50:56 <jbk> ok
23:50:59 <rmustacc> What matters is where the -L/path and the -lfoo is.
23:51:33 <rmustacc> If your -l is before the required -L we won't find it on that path, IIRC.
23:53:28 <jbk> does the 'default search path' that it'll assert on also include anything set via LD_LIBRARY_PATH when invoking ld?
23:54:46 <jbk> (for some reason, in our internal illumos build, after we (finally) switched to gcc10, debug builds are failing building the platform's (i.e. not bootstrap) perl
23:54:57 <jbk> because it's finding libc.so
23:55:05 <jbk> but the error message doesnt' say where
23:55:27 <jbk> but the parameters passed to perl's configure script all look correct to building using the proto area
23:55:35 <jclulow> tsoome: What would you like me to say about it!
23:57:13 <rmustacc> jbk: I read ld(1) that LD_LIBRARY_PATH is treated as similar to -L.
23:57:18 <rmustacc> But I don't know more than manual page.
23:57:42 <rmustacc> LD_DEBUG=libs, probably would help say where. Sorry the error message isn't as helpful as it could be there.