01:52:51 <rzezeski> the 700 series is full of bad decisions and sadness
01:57:37 <jbk> yeah, unfortunately we're stuck with it for a while though
06:35:05 <gitomat> [illumos-gate] 14998 smbd domain cache broken -- Gordon Ross <gwr⊙rc>
06:39:22 <gitomat> [illumos-gate] 14988 smb: panic in smb_common_open after pool export -- Gordon Ross <gwr⊙rc>
13:53:02 <jbk> hrm.. anyone seen where a dump taken with reboot -d looks more like a live dump (with inconsistent/bad data scattered in the dump)?
14:20:29 <danmcd> Maybe?  But I don't know how it originated from the customer.
14:26:45 <jbk> like.. there's at least one bad entry in the symbol table (so annoyingly tab completion trips an assert in mdb)
14:44:49 <jbk> oh not even an assert, msg just flat out segfaults
15:26:30 <jbk> hmm.. probably an odd request, but is there a way to tell mdb to not load any symbol info for a particular kernel module?
15:47:12 <jbk> hmm.. this is interesting.. when mdb is chasing down the loaded kernel modules from the crash dump, the nfs kernel module is what's hosed.. though not clear if that's due to contents in the dump or something with mdb
16:24:02 <jbk> ok.. in a _non-debug_ kernel, are there still things that will scrub memory with sentinels (e.g. 0xbaddcafe)? I know kmem debugging does that after free, but that's not enabled here
16:24:48 <yuripv> you could still enable it using kmem_flags?
16:24:58 <jbk> it's not enabled here
16:25:05 * yuripv hides
16:25:39 <jbk> but something has scrubbed that into a 'struct module' in the kernel
16:25:51 <jbk> so i'm trying to figure out what things it could be
17:02:53 <jclulow> jbk: KMC_NOTOUCH maybe?
17:19:30 <jbk> aha!
17:22:37 <danmcd> Do tell?
17:25:27 <jbk> kmem_dump_init() writes out the uninitialized pattern out to kmem_dump_start
17:27:26 <jbk> for reasons, the system hadn't had dumps configured, so they had to be setup then reboot -d to grab the state of some misbehaving stuff
17:28:45 <jbk> (still would be useful to make mdb a bit more robust here)
17:29:06 <danmcd> Oof.
17:31:21 <jbk> though..dumping more of that (it happens to be right on a page boundary) only the first 40 bytes seems to have that pattern..
19:21:02 <gitomat> [illumos-gate] 15021 upanic recursive mutex enter -- Robert Mustacchi <rm⊙fo>
21:02:21 <richlowe> have any of you seen objdump's --visualize-jumps actually work?
21:14:36 <gitomat> [illumos-gate] 15008 expose bhyve kernel interface version wider -- Patrick Mooney <pmooney⊙pc>
21:15:55 <jbk> hmm.. it looks reasonable picking a random shared library (I'm assuming -d --visualize-jumps ....)
21:16:02 <jbk> at least on this version
21:16:12 <richlowe> ok, so it does work _somewhere_ at least, that's good to know
21:16:16 <jbk> (though it'd be nicer if it'd use the line drawing characters on UTF-8 locales)
21:47:05 <jbk> this is 2.37
21:47:21 <jbk> i haven't tried it on other objects
21:48:50 <jbk> right now i'm trying to track down if there's a way w/ the go s3 sdk to stop it from trying to create hundreds of connections within a few seconds
21:49:07 <jbk> (it turns out some firewalls get some heartburn when that happens)