00:14:54 <richlowe> I still hold out I'll get to "know the guy who killed X11"
00:14:59 <richlowe> with the stake, and the ritual
01:17:43 <jclulow> you cannot kill the undead richlowe
03:26:25 <gitomat> [illumos-gate] 16981 pbchk should probably bail early on long commit series -- iximeow <illumos⊙in>
03:26:25 <gitomat> [illumos-gate] 16982 pbchk could have a better user agent -- iximeow <illumos⊙in>
08:27:46 <tsoome> New record with zfstest: Results Summary
08:27:46 <tsoome> PASS     1286
08:27:46 <tsoome> SKIP       1
08:28:20 <tsoome> Note: flip-flops are still there, just this time they are at PASS side:)
08:45:14 <dangergrrl> I'm looking at filesystem stuff tonight :)
11:51:21 <andyf> tsoome - that's brilliant!
13:36:02 <Guest44> Hey, I'm sure this has come up a million times so I'm really not trying to offend by asking this: How close is the illumos ZFS implementation tracking OpenZFS?
14:46:33 <gitomat> [illumos-gate] 16977 t4nex should be cstyle clean -- Patrick Mooney <pmooney⊙pc>
17:03:40 <sommerfeld> tsoome: thank you for your work fixing flakey tests!
17:27:49 <tsoome> sommerfeld its necessity, without testkit there is little hard to try to prove we are good (as much as the tests *can* prove).
17:30:01 <jbk> tsoome: nice
17:30:12 <jbk> i can hopefully retire my list of 'known to fail' zfs tests
17:30:18 <jbk> which will be nice
17:30:25 <jbk> they take like 6-8 hours to run
17:32:53 <jbk> perhaps a silly question, but when an NMI received is there any other additional context/info surrounding it that can be examined?
17:32:54 <tsoome> we still do have several flipping, like l2arc ones, which do need l2arc fixes. 
17:37:29 <tsoome> am.. surrounding it? like other threads currently on CPU?
17:38:45 <jbk> more about what caused it? e.g. you can manually trigger one, but are there other things that would generate one (and if so, is there any way to distinguish between them)?
17:39:00 <rmustacc> Not architecturally.
17:39:59 <jbk> there's a lab box (not our lab) where an NMI is occurring about once a day.. we suspect it's something in the lab doing this, but don't want to dismiss other possibilities if such could exist
17:40:25 <rmustacc> The answer is going to be processor/board specific.
17:41:07 <rmustacc> There are definitely other things like still have old school PCI errors enabled or parts of the I/O APIC redirection table.
17:41:24 <rmustacc> ON some processors SMI's can lead to NMIs too.
18:52:05 <gitomat> [illumos-gate] 16760 Source code contains man page cross-reference errata -- Chris Fraire <cfraire⊙mc>
19:40:19 <gitomat> [illumos-gate] 16674 dev_err(9f) doesn't do anything useful with CE_PANIC -- Robert Mustacchi <rm⊙fo>
19:49:12 <richlowe> hurray
20:31:01 <gitomat> [illumos-gate] 17008 ZTS: left over file /var/tmp/file.pidnum -- Toomas Soome <tsoome⊙mc>
21:36:14 <jclulow> jbk: I assume the machine has a BMC or whatever?
21:36:36 <jclulow> Are there audit logs or whatever for IPMI actions in there?
21:36:53 <jclulow> (Does it stop happening if you unplug or wall off the BMC for a few days haha)
21:37:04 <richlowe> a subtle but good idea
21:38:05 <jclulow> I've always been sceptical of machines where NMIs just happen from time to time, motivating that Linux message about "haha, nmi, continuing" or whatever
21:38:23 <jclulow> While anything is possible I would always blame a BMC first lol
21:38:38 <richlowe> yes, I was always trying to get from Keith the _specifics_ of whatever machine generated one during boot, and made our NMI handling suck
21:38:55 <jclulow> Yeah I have no data
21:39:21 <richlowe> if it was like, one of Sun's x86 blades I'm absolutely willing to say "We should NMI properly, and if that backfires we'll undo it again"
21:39:24 <richlowe> and say sorry a lot
21:39:48 <richlowe> v. if it's actually a thing that happens to normal people, and we can really see that being true
21:40:26 <nomad> joeaveragedev . o O ( NMI? Not My Interrupt )