06:21:27 <gitomat> [illumos-gate] 15086 ccid mistakenly thinks F_AUTO_PARAM_ATR means params are required -- Lexi Wilson <lexi⊙cn>
08:41:19 <cgr> is there anyone how is familiar with the Solaris 11.4 mdb command ::deadman_journal? I try to investigate a Solaris 11.4 guest hang on Omnios Bhyve and I have a crash dump initiated by set kernel parameter snooping=1.
08:41:45 <cgr> this shows deadman_journal
08:41:45 <cgr> vmcore.5> ::deadman_journal
08:41:46 <cgr>   CPU  LOG#        TIMESTAMP  INTRACTV     NRUN           THREAD
08:41:46 <cgr>     0   299        21871650d      4000        2 fffffffffc235b00
08:41:47 <cgr>     1   298        227588bba      4000        0 ffffe33000f7dac0
08:41:47 <cgr>     1   299        225d5a7aa      4800        1 ffffe33000e5bac0
08:41:48 <cgr>     2   299       dc1b40dcd9      4000        0 ffffe33000cfaac0
08:41:48 <cgr>     3   299        225d8d4b9      4000        2 ffffe33000bffac0
08:53:20 <tsoome> havent used it. name is kind of self explanatory, I'd check the thread stacks where NRUN column entries are not 0, also LOG# column would seem to suggest there are log entries for deadman?
08:54:40 <tsoome> in general, deadman fires on resource starvation - the immediate suspect would be disk IO (being the slowest resource there).
08:55:25 <jclulow> cgr: Does "::help deadman_journal" work?
08:58:02 <jclulow> Also, if it's related to "snooping", that's generally something getting in the way of clock() I think, rather than some of the ZFS I/O or pageout deadmans
09:02:24 <cgr> The timestamp of CPU 2 is much different, could be normal?
09:02:32 <cgr> vmcore.5> ::help deadman_journal
09:02:32 <cgr> NAME
09:02:33 <cgr>   deadman_journal - display the deadman journal
09:02:33 <cgr> SYNOPSIS
09:02:34 <cgr>   ::deadman_journal [-v] [-c <CPU>]
09:02:34 <cgr> DESCRIPTION
09:02:35 <cgr>   Displays the contents of the deadman journal.
09:02:35 <cgr> OPTIONS
09:02:36 <cgr>     -c <CPU>    display content for the given CPU only
09:02:36 <cgr>     -v          report interrupt statistics in nanoseconds
09:02:37 <cgr> ATTRIBUTES
09:02:37 <cgr>   Target: kvm
09:02:38 <cgr>   Module: genunix
09:02:38 <cgr>   Interface Stability: Unstable
09:22:16 <cgr> some data here: https://pastebin.com/45UHaAhS
10:07:02 <tsoome> well, the ffffe33000c29ac0::findstack at line 120 is interesting and is indeed pointing towards time management as you are getting panic from cyclic_expire() 
13:20:50 <carba> some data more data form threads on CPU 1 here: https://pastebin.com/wy33kjhi
15:23:19 <jbk> hrm..
15:31:12 <jbk> from the mac man pages, it suggests for MAC_CAPAB_RINGS, for TX rings, you can specify a group count of '0' but with > 1 rings, correct?
15:31:48 <jbk> looking at mac_init_rings(), it appears that will cause the mr_rget() func to be called with a group_index of -1
15:32:24 <jbk> which doesn't appear to be a value specified in the man pages
15:32:37 <jbk> so not sure if this is a mac bug or a man page bug
15:33:21 <jbk> (my assumption was that for such a scenario, the group index passed to mr_rget() would be '0')
20:00:11 <gitomat> [illumos-gate] 18261 want apic_id in cpu_info kstat -- Andy Fiddaman <illumos⊙fn>