03:19:55 <jbk> has anyone done anonymous dtrace on smartos? I'm guessing I probably need to make the resulting dtrace.conf file (from dtrace -A) into a boot module, but not sure if there's more to it or some other trick
03:22:00 <rmustacc> That should be it. And a forceload.
03:22:18 <jbk> ahh.. so also make /etc/system a boot module too..
03:22:24 <jbk> (w/ the forceload statements)
03:22:52 <rmustacc> I don't believe you need anything in /etc/system.
03:23:01 <rmustacc> Forceload usually goes in the module's .conf.
03:23:13 <jbk> oh hrm.. i always remember them being in /etc/system
03:23:25 <jbk> but it's been a long time since i've had to mess w/ them...
03:23:49 <rmustacc> No, generally it's a 'ddi-forceattach=1' in the .conf.
03:24:07 <rmustacc> That's what happens in all the USB HCDs, etc.
07:30:39 <andyf> jbk I have followed the instructions in https://wesolows.dtrace.org/2013/12/28/anonymous-tracing-on-smartos/ before. Which reminds me that I need to start an IPD that will help with a mechanism to make this transparent.
14:41:20 <jbk> ahh nice... looks like i was pretty much on the right path..
14:41:47 <jbk> didn't have enough time last night to start on it, but hopefully will be able to get to it sometime this week
14:43:13 <jbk> i had tried to use kmdb to track down my kcf issue, but it's happening far enough in the boot process where a bunch of kernel threads are running (and I think at least some userland), so while tracing one thread, a different thread causes the panic (and the context I'm trying to look at is gone by then)
14:43:29 <jbk> but not so late enough I can login to the console and run dtrace
14:43:45 <jbk> so anonymous dtrace seems like a better option
14:44:12 <jbk> (and probably more fun too, and since this is just a personal project... at least for now)
15:33:23 <rmustacc> That is the kind of thing I'd look to anonymous DTrace for.
17:01:24 <gitomat> [illumos-gate] 16070 Drivers for ATTO Celerity FC-162E Gen 5 and Celerity FC-162P Gen 6 16GB FC cards support -- Hans Rosenfeld <hans.rosenfeld⊙nc>
17:04:51 <gitomat> [illumos-gate] 16078 `fcadm force-lip wwn`: Failed to reinitialize the link of Emulex HBA -- Rick McNeal <rick.mcneal⊙nc>
17:07:07 <danmcd> @Woodstock do these need driver_aliases entries in packaging?  Or does that come in a subsequent push?
17:11:00 <Woodstock> i have no idea :)
17:11:44 <Woodstock> i don't see any new driver_aliases for those in omnios, which is were these commits were coming from
17:13:17 <danmcd> Ahh beautiful.  Thank you.
17:13:53 <danmcd> https://code.illumos.org/c/illumos-gate/+/3154/  has pkg manifest updates.
17:13:54 <fenix> → CODE REVIEW 3154: 7288 qlt/qlc integration & cleanup (NEW) | https://www.illumos.org/issues/7288
17:17:03 <Woodstock> yes, but thats an entirely different driver :)
17:20:39 <Woodstock> hm. i just found the missing driver_aliases entries.
17:20:51 <Woodstock> i guess whoever used these cards with omnios added them themselves.
17:42:26 <danmcd> Wow.
17:42:39 <danmcd> File a followup, if nobody noticed with Omni, nobody will notice with -gate.
17:42:48 <danmcd> And don't make it a high-priority.